Topic: SaLiVA - new format

[Fanny Pack]

Getting ahead of ourselves but it would be possible to combine all sorts of methods for drawing.  For example, here is a frame with 3 lines.  1 white lines, 1 red line, and 1 line that changes from red to yellow. 

I am not suggesting these primitives or syntax but it should give you some ideas.

<Frame number="1">
  <Points>
   <Point x=0 y=0 color="000000"/>
   <Point x=0 y=100 color="FFFFFF"/>
  </Points>

  <Lines>
    <SolidLine x0="0" y0="100" x0="100" y0="100" color="FF0000"/>
    <GradientLine x0="100" y0="100" x0="100" y0="0" color0="FF0000 color1="FFFF00"/>
  </Lines>
</Frame>

[James]

Code: [Select]

<FILETYPE>
<FRAMESET name=frame_set_01>
<FRAME>
<!- A white square -->
<POLYLINE name=object_01>
<VERTEX location=(0, 0) color="#ffffff">
<VERTEX location=(0, 20000) color="#ffffff">
<VERTEX location=(20000, 20000) color="#ffffff">
<VERTEX location=(20000, 0) color="#ffffff">
</POLYLINE>

<!-- A red circle -->
<CIRCLE center=(0,0) radius=20000 color="#ff0000">
</FRAME>
</FRAMESET>
<FRAMESET name=frame_set_02>
<FRAME>
<!- Another white square -->
<GROUP name=object_2>
<VECTOR origin=(0, 0) magnetude=20000 rotation_z=0 color=#ffffff>
<VECTOR origin=(20000, 0) magnetude=20000 rotation_z=90 color=#ffffff>
<VECTOR origin=(20000, 20000) magnetude=20000 rotation_z=180 color=#ffffff>
<VECTOR origin=(0, 20000) magnetude=20000 rotation_z=270 color=#ffffff>
</GROUP>
<LINE name=object_03 origin=(-32000, -32000) destination=(32000, 32000) style=gradient color=(#0000ff, #ffff00) >
</FRAME>
</FRAMESET>
</FILETYPE>

This means we need to be able to read things like coordinate pairs and triplets like (x,y) & (x, y, z).

This also means that these objects have to be designed with a set of attributes that are all pre-defined ~ with default values.

BTW What is the size of our new universe?

Is it real?

How is using notation like #ffffff not "designing for past technology" ?

James.

[Agent C]

I like defining everything between -1.0f and 1.0f for space and 0.0f and 1.0f for colors.  This way it's easy to turn up or down the precision.  That's what sgi did back in the day so their systems could support 16 bit color early on and 48 bit before they got out of making workstations.

Here is a sample of a POVRay scene.  It came about before XML, but pretty much lends itself to XML, and XML is fine with me.

http://www.povray.org/documentation/view/3.6.1/224/

A little background - povray is an opensource ray tracer.  The scene files sort of read like C source code.  Like our format should, it supports object primitives, splines, and point lists.  Camera and lightning might be a bit much for our laser purposes, and I don't think primitives need to have textures either - but you can always skip the parts you don't want. 

#version 3.6;
 #include "colors.inc"                                      //Includes a separate file defining a number of common colours
 global_settings { assumed_gamma 1.0 }
 
 background   { color rgb <0.25, 0.25, 0.25> }              //Sets a background colour for the image (dark grey)
 
 camera       { location  <0.0, 0.5, -4.0>                  //Places a camera
                direction 1.5*z                             //Sets, among other things, the field of view of the camera
                right     x*image_width/image_height        //Sets the aspect ratio of the image
                look_at   <0.0, 0.0, 0.0> }                 //Tells the camera where to look
 
 light_source { <0, 0, 0>                                   //Places a light source
                color rgb <1, 1, 1>                         //Sets the color of the light source (white)
                translate <-5, 5, -5> }                     //Moves the light source to a desired location
 
 box          { <-0.5, -0.5, -0.5>,                         //Sets a first corner of a cuboid
                <0.5, 0.5, 0.5>                             //Sets a second corner of a cuboid
                texture { pigment { color Red }             //Sets a color for the box ("Red" as defined in "colors.inc")
                          finish  { specular 0.6 }          //Sets how the surface of the box reflects light
                          normal  { agate 0.25 scale 1/2 }  //Sets a bumpiness for the box using the in-built model, "agate"
                        }
                rotate <45,46,47> }


NIt also supports variables, math operations, and simple looping constructs.
 #declare the_angle = 0;
 
 #while (the_angle < 360)
    box {   <-0.5, -0.5, -0.5>
       <0.5, 0.5, 0.5>
                texture { pigment { color Red }
                          finish  { specular 0.6 }
                          normal  { agate 0.25 scale 1/2 } }
       rotate the_angle }
    #declare the_angle = the_angle + 45;
 #end
       

[BlinkenLights]

well think that #FFFFFF notation is ok "256,256,256" is ok too. There is no alpha layer with lasers.
 

[Fanny Pack]

You POVRay example is interesting.  I hadn't thought of being able to add logic to the file in order for it to be self animating.  Perhaps we could also define a set of standard effects that could be added directly to the file.  For example, rotation and translation are pretty standard.  The notion of time would have to be added to the file, obviously.  I think that this type of thing could come later as long as we keep in in mind as we move forward.  If each portion of the image is an object then we can extend those objects later in XML and in code to contain logic to make them move independed of the rest of the image.

Now we're getting somewhere.

[BlinkenLights]

absolutely.. if i have a group of primitives that make up the body of a person and inside the main group there are groups for the arms legs etc, and then the hands forearms etc. i should be able to move the entire thing all at once, or move each subgroup seperately.

we need to make sure that there is a unique ID assigned to every primitive using positive real numbers. and the groups need the same things.


we have 3 areas so far.
#1 actual drawn data (points lines curves)
#2 descriptive information (color, whatever)
#3 Logic (programed movement)


This sounds alot like a file that may be used to control a machine  for industrial purposes. The instructions have got to be translated to something that is real and compiled. Thats ALOT of code and logic to make happen.

[BlinkenLights]

ok gary, draw me a picture (in xml) of a white circle that is as large as possible. and an X that is also as large as possible(not the letter just connect the corners of the display area)

[Fanny Pack]

I'd do it just as I have shown before.  Using two line objects and a circle object.   As far as making it maximum size goes, that is something we haven't discussed.  We don't have to limit the image to what can be displayed.  For example, I think it is acceptible to define a circle off screen and have it move across the visible area and then off screen again.  So, there is max coordinate space and max visible coordinate space.  If we want a 3D space then it make sense to define things like perspective, camera angle, camera direction, etc since that defines the view port.  And by doing so, that could be changed in real time so as you watch the laser show you can actual move around it.  That is basically what Zoof did with his 3D laser world application.

I don't have an answer to your question because it depends on how other things are set up and that can be very complicated or very simple.  So, again, lets forget about specifics of notation and think more about what we want to encapsulate.

[Agent C]

I like the camera idea, and not just because I rely on OpenGL.  If you're going to have 3d space, you need to define the camera.  There can be a standard or assumed camera definition, but no matter what you have camera, and with that camera there is a certain depth of field and viewing angle etc, etc, that is used in calculating perspective.  The povray definition for the camera is pretty robust.  The camera and it's associated values thereby define what areas are viewable and what areas are not viewable.

How about the world space be a single or double float.  Then people like me can make everything fit in -1.0f to 1.0 or if you like doing things to scale you can make it really huge.  As noted above, Camera setup will always determine what's viewable and what isn't.  Since we're talking laser shows and not launching the space shuttle I don't think we'll suffer much from using floats.

[BlinkenLights]

ill say it before james does...

equidistant or perspective?

[Fanny Pack]

Perspective is what allows you to view a 3D object on a 2D surface and make it look 3D.  I'm not sure what you are asking.

[BlinkenLights]

well in laserboy, when you view a cube from the front it looks like a square..
in zoof 3d when you look at the front of a cube, you can see thru it and the back face seems smaller than the front face because its further away.. perspective...

[Fanny Pack]

It would be confusing to edit an object while it is being shown with perspective.  But during normal viewing it makes sense to project it in 3D.  But it doesn't matter because it is something that can easily be turned on or off.  It's just a transformation.

But what this makes me think of is the concept of shapes having fronts and backs.  If zoofs stuff had fronts and back you would not be able to see through the cube to see the back.

Perhaps the notion of 3D, fronts, backs, animation, etc is a bit much.  It definitely belongs in the application creating the images. But when saved to the file is it that important?  I can see that defining advanced shapes without optimized points is beneficial but I don't know how far past that it makes sense to go.  I'd be happy with just a 2D frame with high level draw instructions in it.  This frame could/would be created by an application that takes some of the technology that we are discussing and applies it.

[BlinkenLights]

james and i discussed this..

I have a solution.. its called FILL or TEXTURE..

here is the COOL thing i thought of.. it does not have to be JUST blanking behind a solid texture.. a texture could effect what is behind it like a colored window. and textures could be 2 sided ..

[James]

One thing that I think is SUPER IMPORTANT is the syntax of the language.

In the POVray code example

thing
{
    parameter value
    another_thing
    {
        parameter value<0.0, 0.0, 0.0>
    }
}

We have to come up with a set of control characters and conditions that apply with enough sense to be able to (human) write it, computer write it and computer read it!

This means that we should be thinking about the lexical analyzer and how to convert this into computer action.

I'd also like to see a good expression evaluator!

BTW I am totally on board with using real numbers from -1.0 to 1.0.

James.