LaserBoy

Software => Joint Development => Topic started by: BlinkenLights on April 03, 2009, 06:35:47 pm

Title: SaLiVA - new format
Post by: BlinkenLights on April 03, 2009, 06:35:47 pm
SaLiVA is Standard Laser Vector Art
or Super Awesome Laser Vector Art

The idea is to have a file type that that is truly flexible and usable from both an artistic and technical standpoint.

all good projects start with a great name (i know thats not true)


Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 03, 2009, 07:24:54 pm
Hmmm, maybe we can work on the name later...
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 03, 2009, 07:33:16 pm
ok how about it.. im thinking we store info as splines and primitives.. and then the software reads the vector data and creates output.. so a circle will only have 1 point (its origin)

Title: Re: SaLiVA - new format
Post by: Agent C on April 06, 2009, 03:42:11 pm
Take a look at the POVRay file format.
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 06, 2009, 03:48:06 pm
no YOU take a look at it.. im just the idea guy ya see.. i dont do the hard work..
I just pop off at the mouth constantly and eventually something smart comes out...

Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 06, 2009, 04:06:20 pm
:)  I think we are all pretty much that way.  I guess that's why nothing ever happens.
Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 04:08:12 pm
I'm trying, but nobody listens to me!

In the mean time, I'll just keep putting good ideas to work in LaserBoy, even if no one else ever finds them or uses them!

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 06, 2009, 04:12:13 pm
well something needs to effing happen.. all this brain power in here, there is no excuse.. we just need to put our heads together and figure this shit out..

Here is a list of things i believe a new file structure should have.

Framed data and linear data layouts
(one is for animation of complex shapes the other is more like an abstract over time where the frames dont matter)

True vector storage of shapes, no extra points required

Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 04:27:18 pm
There is a lot of room for new ideas and improvements in laser display; not just in the file storage catagory.

Although.... if you want to start there, how about a uniform way to store color vector laser data in plain ASCII?

That way people could make frames in a text editor.

James.
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 06, 2009, 04:51:54 pm
Does anyone not think XML is a good starting point?  I'm not saying that it is the best solution in the long run but if we are going to start designing something i think it is the best choice since we can all look at it and read it without having to twiddle bits.  It's also very object oriented so it lends itself to being able to describe anything from vectors all the way up to frames.

But, I'm jumping ahead.  First thing would be to make a wish-list of every feature that we would want to go into the file.  So add yours and everything is fair game.  And please don't start arguing about what other people put on their lists.  We can debate the pros/cons of everything later and decide on what goes and stays later.

With me?
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 06, 2009, 04:58:28 pm
ABSOLUTELY ! !

a XML data structure is something that makes tons of sense..

its simple ascii and on top of that it compresses well.

it could be used as either the descriptor file for the vectors (aka vector id 1 fades from #333333 to #000000)

it could be used as actual shape storage
Code: [Select]
<shape>
    <curve>
        angle= blah
        size = blah.....
        etc.....


thats where we need to be exploring..

Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 05:55:34 pm
Whatever it is should be something that is also implemented in open source code.

Generic C++ would be the best language to use.

All of the code necessary to write, read and interpret the ASCII should be part of the distribution.

James.  :)
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 06, 2009, 06:52:57 pm
Whatever it is should be something that is also implemented in open source code.

Generic C++ would be the best language to use.

All of the code necessary to write, read and interpret the ASCII should be part of the distribution.

James.  :)

Why?  Standards are never implementation specific.  It's fine to give examples in your language of choice but ultimately it's up to the developer to decide how they want to implement it. 
Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 06:54:11 pm
That's absolutely true!

However, if it is implemented in code that proves that it's a bit more than just a good idea!

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 06, 2009, 06:55:14 pm
yes at some point it has to actually work...


Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 06:59:34 pm
Getting it to work requires development.

That imposes a choice.

James.  :)
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 06, 2009, 07:14:36 pm
Anyway, until you decide what you want to achieve it is pointless to start building anything.  So, back to the list.
Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 07:27:23 pm
That's partly true, but I had no idea that I would work my way toward so many neat features in LaserBoy until I had built a bridge through thin air to get there.

Working with just the tiniest bits of information can tell you a lot about what "it" wants to become.

LaserBoy talks to me all the time! He tells me what to do next and how to do it!

James.  :)
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 06, 2009, 07:39:12 pm
Well I don't want to spend time Forrest Gumping my way through this.
Title: Re: SaLiVA - new format
Post by: James on April 06, 2009, 09:55:59 pm
You have such a way with words.

How would you go about it?

Would you design the whole spec first and then code it?

In what?

What if you can figure out how to implement your own ideas?

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 07, 2009, 08:05:50 am
no.. figure out what we want to achieve.. figure out how we plan to achieve that logically then start coding. he said that already.

i would like a file that can store some sort of instructions for movement over time.. maybe..

Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 07, 2009, 10:41:16 am
Right.  First step is to figure out what we intend to do.  I assume we are talking about a next generation ILDA type format that can be shared between different applications?   So, what are the limitations/problems of the ILDA format?  Here is just what is at the top of my head.
(1) Too many different formats.  One format that does it all would be better.
(2) No way of adding data such as description, required projector colors, author info, etc.  Actually there are about 16 bytes that can currently be used but they aren't enough to be useful.
(3) It might be better to not specify every point and instead use something like beziers or shapes.  Software could be used to create the path points based on speed, scan angle, etc.  This prevents having to add optimization data to the image description.

That's a start.
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 07, 2009, 11:10:51 am
i hate the fact that with an ilda file i cant change colors without adding a scan point.
i get why its like that, but if i want to draw a straight line and i want a linear fade from cyan to magenta, thats all the information i should have to give it. let the software figure out what to do with it.

Title: Re: SaLiVA - new format
Post by: James on April 07, 2009, 02:51:28 pm
That's a neat idea.

We should always keep in mind that we are planning on creating information that will be shown on a laser projector, and keep reality in the mix.

Meaning:

Your idea is good because it takes less information to describe something and it could easily be rendered on-the-fly.

And if it is calculated, there is less of a chance of incorrect data.

But, we also need to think about how long a projected line would need to be in order to even see the effect that you want. Remember, this is still going to be clocked out as discreet points. If you want to draw a nice line from hear to there, it will take some number of points.

Also in a 24-bit rgb color system, there are only so-many colors between any two.

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 07, 2009, 04:08:49 pm
but what if i make "from here to there" bigger as in, i do it at 96k or 120kpps (in the future) i want there to be a perfect fade.

Title: Re: SaLiVA - new format
Post by: James on April 07, 2009, 04:22:03 pm
That's all part of the question!

BTW If you really wanted to, you could start with 8 bits each for RGB colors and derive 15 bits of variation (16-bit signed short int) out of that with a color blend. Then you DAC out each of the RGB values as a 16-bit number.

Hmmmmmmm I wonder what format that would be?  ::) ;)

That's the nice thing about an ASCII solution. We can use text numbers with arbitrary precision. We don't need to worry about atomic data types.... just yet.

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 07, 2009, 04:33:40 pm
agreed.. and its also nice to be able to go in a tweak a text file or parse it with a global add and replace to change something
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 07, 2009, 05:05:22 pm
That's a neat idea.

We should always keep in mind that we are planning on creating information that will be shown on a laser projector, and keep reality in the mix.

Meaning:

Your idea is good because it takes less information to describe something and it could easily be rendered on-the-fly.

And if it is calculated, there is less of a chance of incorrect data.

But, we also need to think about how long a projected line would need to be in order to even see the effect that you want. Remember, this is still going to be clocked out as discreet points. If you want to draw a nice line from hear to there, it will take some number of points.

Also in a 24-bit rgb color system, there are only so-many colors between any two.

James.  :)

It isn't necessarily going to be clocked out as discreet points.  In your implementation it might but in someone elses future design their "smart" scanner may be fully capable of knowing a start point and color and end point and color and linearly modulating the lasers so that they provide a gradient color change over the step.  This is why you need to stop thinking about how you can do it and start thinking of what you want to do.  Otherwise, you will always be designing for past technology.
Title: Re: SaLiVA - new format
Post by: James on April 07, 2009, 05:29:02 pm
I guess this is yet another variation on the old-old-old argument about analog vs. digital.

It all comes down to the fact that BOTH of them have ultimate limitations to resolution and signal to noise ratio.

So really all we need to worry about is the REAL finality of the "time quantum" of human perception of the information streams.

Just as you can not reliably hear above 30KHz, you can't see beyond certain limits of rate of change of light either!

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 07, 2009, 10:15:43 pm
i disagree...

by thinking inside this box you limit the flexability of design..

who is to say that i can modulate my laser with a true analog signal..

software could be written that sends instructions to a box that actually modulates the laser with a true analog signal, just like me twisting a knob..

in the SAME breath the same software may be ablt to do the same thing for scanners..

yoou say point a to point b and some other information about the math of the curve, and it does it in the analog domain..


obviously this is an extreme example, but the file should store data in the most accurate way possible..

That being said, what about starting with a BASIC set of primitives like POINT and  LINE. build on that descriptive atributes like LOCATION , ANGLE, ROTATION, COLOR, ETC, ETC...



just a thought...


my idea is to describe the art in its purest form...  kinda like the way that FLASH, ILLUSTRATOR and COREL DRAW do...

Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 07, 2009, 10:37:11 pm
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>

Title: Re: SaLiVA - new format
Post by: James on April 07, 2009, 11:22:33 pm
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. :)
Title: Re: SaLiVA - new format
Post by: Agent C on April 08, 2009, 01:29:27 am
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/ (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
       
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 08:04:21 am
well think that #FFFFFF notation is ok "256,256,256" is ok too. There is no alpha layer with lasers.
 
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 08, 2009, 08:49:42 am
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.
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 09:39:45 am
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.

Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 10:47:24 am
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)





Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 08, 2009, 11:16:31 am
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.


Title: Re: SaLiVA - new format
Post by: Agent C on April 08, 2009, 01:17:28 pm
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.
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 01:23:54 pm
ill say it before james does...

equidistant or perspective?


Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 08, 2009, 01:28:51 pm
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.
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 01:46:46 pm
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...
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 08, 2009, 02:14:20 pm
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.

Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 02:19:47 pm
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 ..

Title: Re: SaLiVA - new format
Post by: James on April 08, 2009, 02:50:32 pm
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.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 03:18:24 pm
syntax shmintax....

we are not quite ready for code yet.. the file format idea is shaping up but its not in any way complete.

<thing>
    <parameter>value</parameter >
    <parameter2>value</parameter2>
</thing>

<thing2>
    <parameter>value</parameter >
    <parameter2>value</parameter2>
</thing2>
Title: Re: SaLiVA - new format
Post by: James on April 08, 2009, 03:21:08 pm
Once we have some syntax we have the bricks, mortar and cut stones to make our castle.

James.  :)
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 08, 2009, 03:29:20 pm
Until we know what the castle is supposed to look like the bricks are useless.
Title: Re: SaLiVA - new format
Post by: James on April 08, 2009, 03:34:10 pm
NOT TRUE !!!!

The syntax of a language breaks up the tokens. There are LOTS of things to decide that have NOTHING to do with the functionality of the language.

Is it case sensitive?
How do we deal with white space?
How do we deal with newlines?
Does a statement have to be on one line or can it be broken into many?
What symbol do we use for assignment?
How do you know the difference between a parameter and its value?
What limitations are there to variable names?
etc. etc. etc. etc. etc. etc....

Will there be a dynamic object model behind this code?
Can we reference the DOM like we do in HTML?

Could we jack a kind of JavaScript into that to do our animations and on-the-fly modifications?

These things are ALL ABOUT how to parse it back into actionable code!

You can just assume that we are going to take the "look and feel" of another language, but THAT is still a syntax choice!

James. 
Title: Re: SaLiVA - new format
Post by: Fanny Pack on April 08, 2009, 03:37:51 pm
We already decided on XML for now. All of that stuff is already defined.
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 03:39:31 pm
none of the code you write in C++ will effect what gary does in .net or what someone else does in python..

the file structure has to be rigidly adhered to in the writing phase, otherwise the file will fail to be valid.

Now with the structure that XML uses , it can all be on one line because its just look for the next <word> or </word>

it could care less whats in between as long as its empty, spaces, or crlf


Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 08, 2009, 03:41:28 pm
 <recipe name="bread" prep_time="5 mins" cook_time="3 hours">
   <title>Basic bread</title>
   <ingredient amount="8" unit="dL">Flour</ingredient>
   <ingredient amount="10" unit="grams">Yeast</ingredient>
   <ingredient amount="4" unit="dL" state="warm">Water</ingredient>
   <ingredient amount="1" unit="teaspoon">Salt</ingredient>
   <instructions>
     <step>Mix all ingredients together.</step>
     <step>Knead thoroughly.</step>
     <step>Cover with a cloth, and leave for one hour in warm room.</step>
     <step>Knead again.</step>
     <step>Place in a bread baking tin.</step>
     <step>Cover with a cloth, and leave for one hour in warm room.</step>
     <step>Bake in the oven at 180(degrees)C for 30 minutes.</step>
   </instructions>
 </recipe>
Title: Re: SaLiVA - new format
Post by: James on April 09, 2009, 12:42:49 am
There are a lot of ways this could go... If we choose a code that looks enough like XML, SVG, VRML or whatever, we could then go on to develop a document object model and an active script language for it.............. AND.................

Actually create a new definition for Internet distributable content via HTTP !!!

So, a player application could be on any computing platform and convert the text and associated binary information (like MP3) into a laser show!

Laser shows could be served over the web to your "laser show enabled" browser!

The HTTP protocal was designed to be extensible to accomodate for new forms of information.

http://en.wikipedia.org/wiki/List_of_vector_graphics_markup_languages

A color laser vector projector could become a computer peripheral, like a raster video projector.

Check this out!!!

http://en.wikipedia.org/wiki/X3D

James.  :)
Title: Re: SaLiVA - new format
Post by: BlinkenLights on April 10, 2009, 02:54:43 pm
Pipe dreams :)

but the example is a great start.. x3d does kinda what we want.. and we are kinda creating our own markup language.

ever think about the file actually calling a separate file with instructions.. like a wave file that has an analog abstract stored in it..


SimplePortal 2.3.7 © 2008-2024, SimplePortal