Topic awaiting preservation: Anyone remember VML?

Vector Markup Language - Was it something invented and exclusively supported by M$? I remember VML being discussed when IE4 or 5 came out and thought that it was part of the CSS specification the way it was talked about, but it turns out that it's this separate thing entirely. I was thinking it might be neat to create some cool 3D polygon code using VML triangles, JavaScript logic and CSS VML control, but it turns out that only IE supports/supported it and I can't even locate a plugin to make it operate on IE6 - what a bummer!

Here's some info on it from M$

I think there is no substitution for VML since SVG and Flash require plugins and perform all kinds of fancy tricks that are beyond the scope of VML's capabilities: simple vector graphics additions to web pages right from the page code itself. This should be part of a widely supported spec so that guys like us can play with it, darn it!

Anyway, my point to posting this was to ask if anyone here has toyed with VML and if you know anything about plugins or whatever to get current IE (or other!) browsers running it. I'm dying to control some real vector triangles with JS!

[edit]I guess I should use the search tool as there are VML topics here on the board. Strange they don't show up in the thread list though. Maybe they're too old.[/edit]

(Edited by esskay on 01-18-2005 23:04)

Okay, I'm a dope. I had cut & paste one example into a doc which didn't work so I assumed VML wasn't working on my IE installation, but another example does work. So nevermind that about plugins for IE. Would be nice if Firefox/Mozilla implements support for it sometime soon though especially given that it is an w3 standard.

No filled triangles or polys in VML though!

VML can draw some filled polygons, and even apply a pattern on them, a bit like the "mapping" techinque in the first "Alone in the Dark" game, or like the patterns you could apply with standard libraries on ST. amikael has played a lot with VML so he could certainly give you some pointers.

The most impressive VML stuff I've seen was actually a rather complex 3D mesh rendered in 3D, but it lacked the perspective projection. Oh and there was the beginning of a raycaster using the polygon functions to draw the walls, but actually my DHTML raycaster was at least as fast and the visual result was better because of the mapping on the walls ( like in Wolfenstein 3D ).

I did som searching on the W3C website
And acording to these posts :
Question
Answer
VML is mircosoft only it's part of the SVG development history.

My search on the W3C

The SVG pages on the W3C site.

------------------------------
Support Justice for Pat Richard

Aww man. I saw this and thought it was an actual specification since it was referred to as "VML Specification" on MSDN developer pages. Hrmph.

Hi esskay.

You can draw filled polygons,

<volyline id="shape" points="100pt, 100pt,120pt,200pt,100pt,175pt,80pt,200pt, 100pt, 100pt"
strokecolor="#0000ff" strokeweight="1pt" fillcolor="#00ccff"/>
I currently work (only on hobby basis, my thesis & part time work takes very much time) with VML stuff.

-kudos

Kudos you should disable slimies in your last post....

------------------------------
Support Justice for Pat Richard

This is using VML: http://www.naltabyte.se/space6

But it's really slow though.
It did make it to Redmond, Microsoft, for a presentation there though, which is it's 'claim to fame' I suppose..

(^-^)b

Thanks for the tips! Here's what I've come up with so far:

http://www.keenkelly.com/demo/vml/

Of course it only works in IE, but I think the performance is fantastic! At this time it has the following features and calculations:

* unlimited 3D points
* unlimited three-point polygons with solid color attribute
* VML polygon rendering
* POV can be moved around in space and rotated on 3 axes
* Back-face culling
* Perspective correction
* fixed 20FPS, but could go faster with lower poly/point counts

In time, what I would like to add are:
* average-based Z-depth sorting
* view window clipping (probably just masking, really)
* light sources and flat shading
* unrestricted multi-point polygons
* solid, reusable object definitions that can be inserted into the world & moved around
* compound objects that have moving parts and connection points such as for character models
* Integration with other rendering types such as ray casting or height mapped terrain.
* finally conversion into a complete, reusable engine that I can then build games on top of

Now that I'm comfortable with the capacity and performance I'm stoked - I don't know how I'm going to get any actual work done anymore!

The very next thing I'll do actually is add points and polys to see how much load this puppy can handle. Will do some more performance optimization on the code where possible before moving forward. I think I'd also like to come up with SOME sort of support for non-IE browsers, even if it's converting the drawPoly output for non-IE browsers to display points and possibly some sort of improvised wireframe so that the world can at least be partially represented.

Thanks again for the responses

(Edited by esskay on 01-19-2005 07:35)

(Edited by esskay on 01-19-2005 07:38)

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

If only browsers were a bit faster *sigh*

The 2D VML engine I made for Naltabyte and amikael here could pontentially be a cross-browser VML since it uses just DHTML, CSS and JS to generate the polygons. It also supports filled polygons made up of beziér curves and/or lines thanks to the filling algorithm. The polygons can be filled with images too since they are really DHTML tags.
Redesigning it for 3D would not be much different and it could even correct the textures for the perspective if needed. Sadly, browsers aren't the best enviroment when it comes to executing code at the speeds needed. But give me 50 years and that should be no problem hehe

As VML is now, I don't see the point with it unless you are specifically designing a 3D tool for IE that needs the rendering speed.

/TwoD

Ooh, now this is nifty.

SK (btw, is this named after combinator calculus? ), I've done some stuff with SVG you might find interesting. I am not sure of the speed comparison between it and VML, but it works in browsers other than IE (I've successfully used MSIE, Mozilla/Firefox/Camino, and Safari).

My main project in it is:
http://www.rpi.edu/~laporj2/

(Speaking of this, the source has been recently updated... it's smaller than before, and features perspective on features.)

Some random source code: (all quite old!)
http://www.rpi.edu/~laporj2/media/code/cube.svg (3D cube.)
http://www.rpi.edu/~laporj2/media/code/gravitation.svg (3D gravitation.)
http://www.rpi.edu/~laporj2/media/code/subdivide.svg (3D Sphere vertex subdivision.)

If I were intelligent on those last three, I'd have dynamically created/destroyed the polygons or points instead of having them in the code, but hey, they're all old.

A few nice things about SVG is that you get all sorts of graphics at your fingertips, cross-platform (Mac/Win), and it's tiny (SVG spec allows gzip compression. The panda on my primary site is 2.6Kb!) I can't wait until XHTML and SVG have progressed to the point where we can include them as namespaces in a single document (which XML theoretically allows, but nobody has implemented that yet -- except maybe the Mozilla SVG project, which I havn't followed all that closely).

"Any sufficiently advanced technology is indistinguishable from magic." -- Arthur C. Clarke
"Any sufficiently arcane magic is indistinguishable from technology." -- P. David Lebling

...my kingdom for a version of FireFox ~10 times faster

Iron Wallaby: Ouch! It's a tricky to get the Adobe SVG working in Mozilla. Add to that I got puzzled by the "Content-Type: text/plain" header returned for the .svg files on your server.



(Edited by poi on 01-19-2005 15:16)

Yes, my server is evil about those. The main page only works since it's included and given it's MIME type. You'll have to download and run those locally.

I had no problems with SVG installations (it's really trivial, I swear )... the nice thing is that, on Mac, it installs automatically so you can run it out-of-the-box. Mac, though, uses the SVG Viewer 3.0 and works fine, so that means that the 3.0 version simply sucks on Windows.

"Any sufficiently advanced technology is indistinguishable from magic." -- Arthur C. Clarke
"Any sufficiently arcane magic is indistinguishable from technology." -- P. David Lebling

Yeah, I'm familiar and have worked with SVG. I used it on a Java Servlet driven website which used Xerces, Xalan and MSSQL Server backend database to build dynamic content which was exported to XML, HTML, PDF and SVG. It's pretty nice, but I'd really like to fiddle around with the native capabilities of the browser to see what can be done without external/plugin software support.

I am curious if anyone has gotten SVG plugin working under Firefox 1.0 though (?) That's my main browser at home and I'd put SVG to more use if I could get it working there.

I wonder if ovals could be used effectively for a VML-based 3D engine... you need to be able to rotate them to arbitrary angles on their center point which I'm not sure SVG has a provision for. I'll have to find out, but they'd make quick work of representing cylindrical shapes.

-SK

PS: My nick is quite unimaginative: my initials! I was quite distraught when I found my usual nick was taken on this board - gah!

quote:

---

esskay said:
I am curious if anyone has gotten SVG plugin working under Firefox 1.0
though (?)

---

Check the link I gave in my previous post
Oh and regarding the rotated ovals, check http://www.croczilla.com/svg/samples/. The first example does almost what you want.

Ahh - custom elipses using arcs might be an option in VML too.. will have to look into that. I'm going to give that SVG plugin a try later tonite - thanks for the tip!

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

^ DirectAnimation.

Well, here's where it's at now. Using keyboard controls (D-pad arrows, plus num-pad arrows (numlock must be ON)) to move around the camera position. Unfortunately I've got all the transformation equations all messed up. I want the camera to behave like a first-person view such that when you rotate on the Y axis, the world revolves around you. It's a simple matter to rotate a single object around a zero-point origin and display the absolute results, but I've never attempted this other model before. So I have to do a little more reading to wrap my head around it

But it's moving along. I've got a simple, slow Z-depth sorter working now. I'm working on some code to change that to a quick sort as soon as I can figure out how to map quickSort technique to my array of objects and the sorting array which represents them.

When I get all the transformations worked out and start in on lighting, I think I'm also going to have brightness diminish with distance which will allow the world to fade to oblivion. It should be possible to make some neat TRON-like landscapes then.

Anyway, I'll probably look further into some more of the things you guys are linking here when I'm done mucking with this. I'm just attracted to the challenge of MAKING this work rather than having a graphics engine handed to me on a silver platter, you know? :lol:

Regards,
-SK

...doesn't Javascript have it's own Array.sort() method that uses an O(n log n) sorting algorithm? You should be able to feed it a function for sorting the elements in any way you desire. It'd save you a lot of time and code!

"Any sufficiently advanced technology is indistinguishable from magic." -- Arthur C. Clarke
"Any sufficiently arcane magic is indistinguishable from technology." -- P. David Lebling

Indeed the sort() method is in spec since JavaScript 1.3. Good shot Iron Wallaby. You can do something like :

p_sort.sort( sortThePolyFromTheirAvgerageZ )



function sortThePolyFromTheirAvgerageZ( a, b )

{

    return polys[ a ].z_avg - polys[ b ].z_avg

}

[edit] Oh, and you'd rather sort by the z_min if you have some large polygons, or if they overlap. Last but not least, if a vertex after its transformation is behind the viewport ( its Z is < z_near ), there's no need to project it, and actually you'll have to clip the edges and polygons including this vertex on the z_near plane. [/edit]



(Edited by poi on 01-20-2005 05:30)

Yeah it does, but I read that it's not terribly efficient. I may give it a try though. Another thing that occurred to me is that CSS has intrinsic support for Z-depth-aware rasterization. Since the polygons are under CSS control, I may be able to get away with simply plugging each poly's z-depth value into the CSS properties for it and let the browser handle the display ordering and then I can do away with sorting entirely.

Well all this needs some experimentation and torture tests to figure which methods works best. Letting the CSS do the sort sounds like a good idea, but I wonder if it's more efficient than sorting a few floats and drawing the polygons in the good order. Which of the JavaScript engine or rendering engine will be faster ?

And further, how best to benchmark it? :lol:

Just a quick update..

I'm now on revision 4 which is here. There are still a good number of tasks ahead, but there are some cool accomplishments that others may find of use on this rev:

1) I have implemented a simple CSS trick to allow the polygons to be displayed on FireFox in wireframe form. It's dreadfully slow to display in this manner, however you can at least "sort of" see what's going on rather than an empty black box. This is all I wanted for non-IE browsers. The code is decently commented to show how it's done, though it's nothing fancy.

2) I have done away with polygon sorting altogether and am now using the CSS z-index value to control the display order - works like a charm! I'm willing to wager that the browser's internal handling of z-depth values will be significantly more optimal than something written in JavaScript.

3) Adding to the z-index capability, I've altered the display to mask the four edges of the viewing window with rectangular tables that mask out the stray polygon edges.

4) Polygon clipping now drops any polygon which is completely off the viewing window from being displayed; anything even partially within view is displayed until you move past it in the z axis.

5) The POV controls have been modified to reflect the control of a first-person perspective within an environment. Previously the controls moved an object around its own axis and displayed the results in a window. Now the window is a view into a world in which the objects sit and you can move your view around the objects.

6) Perspective calculations have been fixed. There is one more bug related to clipping & perspective that swings a distorted take of the world into view if you turn your back to the pyramids. That should be easy enough to fix.

7) I wrote the beginnings of an auto-pilot that would move the POV around the world. Right now I just want the camera to circle around the pyramids and remain aimed at them. However it's been too many years since I've used arctan function and have to do a little more reading to figure out how to do it correctly again. So for now it's just disables with a boolean value at the top of the code.

More to come

Okay, here's something tricky. I want to avoid doing an RGB decimal to HTML hex color code conversion for every polygon of every frame, but I need to be able to adjust color values at the RGB level. Conversion to a hex string requires a heavy text-based routine because for some reason JavaScript seems not to have some intrinsic capability to perform this conversion (which is rather odd to me in and of itself). Anyway, I have been aware for some time that browsers respond to numeric (as well as arbitrary string) values as color codes. I had been assuming up to now that the numeric codes were being interpreted properly as an RGB 24 bit value, but it does not seem to be the case!

function makeRGB(r, g, b) {

	RGB = ((r << 16) | (g << 8) | b);

	return(RGB);

}

This function returns a proper 24 bit RGB encoded value. Unfortunately assigning the color of some HTML entity to that value does not render the proper color on the display! My question is this: is the value used by the rendering engine bit-encoded and I just need to change the way I do the encoding, or is it simply taking the value that I enter as an arbitrary text string and fabricating something that cannot be algorithmically replicated? I REALLY don't want to do dec to hex conversions for every single update - that just seems silly!

Okay, here's what I'm going to do, no JS conversion necessary as CSS can do it for me:

.myclass {color:rgb(255,255,204);}

function makeRGB(r, g, b)

{

   	var RGB = "000000"+( (r<<16) | (g<<8) | b ).toString(16)

	return "#"+RGB.substr( RGB.length-6 )

}

IIRC, assigning directly a 24 bits RGB value works correctly in IE, but of course Gecko refuse that kind of not standard method.

[edit] As a side note, with the rgb(r,g,b); property, IE accepts some floats and clip the r,g,b values in the range [ 0; 255 ], so it may be better to use it in your case. [/edit]



(Edited by poi on 01-22-2005 04:38)

Progress: http://www.keenkelly.com/demo/vml5/

Okay, so the RGB stuff is working. Now if you pull away from the object (numeric pad #2, or link controls in the window) it will fade into the distance until it disappears at the distance which I've specified to be 1500 coordinate units. The color of the object may be any arbitrarily selected 24 bit value and the fade will work the same. I chose a yellowish color to pretend I'm on the Giza plateau for a little while. Some better, more sophisticated object designs will be added soon enough.

This update also corrects a bug in the visibility that was making wild polygons appear then they were immediately behind the POV (perspective calculation does "interesting things" in the Nega-verse). There's one more visibility bug remaining that shows the inner faces of the object somehow if you move the POV to within the object. That should be simple enough. So anyway, now you can completely roam around the object and see it from all four sides (though the controls take some getting used to as they are hard-connected to world space axes - this will be fixed when I change them to be relative to the POV at which point we'll be able to "fly" around the world quite naturally.

Oh, I've also restructured the object relationships in order to support compount objects:

point
poly -> 3 points
solid -> X polys
object -> X solids

This will allow us to produce complex objects with moving parts such as a tank with a rotating turret. The code is done up through the definition of solids and indeed this version is showing the solid model, not simply a collection of global polys. However the code is not yet complete which will transform the solids into the world, so at the moment, the single solid is stuck in the middle of the world at (0,0,0) until I can finish that transform_solids() function.

Once solids are working, we'll be able to insert solids into the world and spind them and move them around as independent entities from one another which should be fun. I'm not quite sure yet just how sophisticated objects are going to be, but I want them to link at least two solids together so that I can indeed make something cool like the tank with turret.

With that capability, then the game development can begin to make something like the old "Arctic Fox" arcade game with such a geometric world and tank sleds that shoot at eachother. Though I'd prefer some sort of laser effect - maybe can even do something killer with laser beam refraction off of polygon surfaces to give mirroring/prisming effects to various solids in the world. Anyway, just daydreaming now.

More coding ahead. I hope as I continue updating this that someone finds it of interest or use and that I'm not just blathering on about petty non-sense that you all worked out 5 years ago. Regardless, keeping you updated on progress helps frame my questions as they come up.

Artic Fox ? coool

Just one detail, is there a reason why you clip the rendering with a TABLE instead of applying the following CSS rule ?

#wnd

{

	overflow:hidden;

}

WoW

Neat stuff going on here.

*dumbfounded UC goes to Suho's Labratory to steal ... err, browse for Tentacle porn.*

______________
Is This Thing On?

Webbing; the stuff that sticks to your face.

quote:

---

poi said:
Just one detail, is there a reason why you clip the rendering with a TABLE instead of applying the following CSS rule ?

---

Only my unawareness of said rule - I will implement it! I also finished the solid model transformations last night and will upload another revised edition a little later today.

And here it is: [url=http://www.keenkelly.com/demo/vml6/}Revision 6[/url]

Thanks for the tip on the overflow:hidden, poi - works like a charm!

So with this version you can see the completed solid model transformation capability. In this demonstration the POV is not moving by itself, its the solid models themselves that are moving through world coordinate space. You can still move the POV around with the controls.

The torus that you see is mad up of 8x10 segments or 80 points which is 160 polygons. Add that to the 6 polygons per pyramid in the middle and you have before you the cumulative effects of 172 polys being double-transformed for every frame. On my poor little Intel P4 2.4Ghz desktop, the framerate is dreadfully low (around 2.5FPS ).

So there are a couple of ideas to attempt to improve the performance. One was mentioned in the discussion above regarding experimenting with sorting algorithms to find whether a coded quick-sort or built in JS array sort , or CSS-based z-depth control methods for each poly would be better or worse than one another. I believe I can lay this quickly to rest however by temporarily disabling Z-sorting entirely and just let the thing display polys unsorted which from an execution timing perspective would show just how much loss is being incurred by the depth sorting itself. I'm not sure what to expect form this experiment.

Another idea to pursue is getting rid of the double-transform by merging the transform_world() and transform_display() functions into a single-pass, comprehensive transformaiton. This would significantly reduce the iterative code that executes for every frame which could have a considerable impact. The down side of this technique however is that without some additional thought it would require everything which appears within the world to be a solid model. Thus no stand-alone polygons could exist because there would be no function to transform them.

That is unless we had a way to identify standalone polys from solid model polys such that in the two-pass approach, the first pass would full transform all solid-model polys and then the second pass would transform all stand-alone polys with no overlap in between. By adding a "type" member to the points[] and polys[] object structures we could also open the door to displaying other types of things in our world view such as sprite images.

Some fun, eh!?

PS: I partly suspect that there is no more performance to be gained from optimizing the transformation process because if you move the POV in towards the center of the torus until you are sitting in the middle of it just in front of the pyramids and the torus is orbiting around you, the frame rate goes WAY up. The only thing that can make the frame rate go up as a result of this move is the fact that there are fewer polygons actually being rendered to the screen. The number of points and polys being transformed is the same, the the number of polys actually being rendered is cut dramatically. This means that the VML poly shape engine just is not up to the task. I will fiddle around with another poly renderer that simply does wireframe, no filled-polys (still using VML) and see what kind of performance can be found from only drawing straight lines from point to point rather than the filled shapes.

(Edited by esskay on 01-23-2005 10:27)

One thing that might/should increase the rendering speed, is actually to cram all the polys in the rendering area ( wnd in your case ) at the initialization stage and then to simply update their visibility, path, fillcolor and zIndex attributes. That way parts of the DOM will be updated but the DOM won't be completely rebuild for each frame.



(Edited by poi on 01-23-2005 15:59)

I'm not sure if I can update their path dynamicall, can I? I had thought about that, but wasn't sure how to access that attribute of the shape. Perhaps it's worth a shot so that all the shapes are allocated and then just moved around. Good thought!

Okay, I added a framerate tracker, then I tried the "preload" method described above where all polys are created in advance of running into the wnd and then only their attributes are modified at runtime. To determine the performance impact of the various types of polygon rendering I tested the resultant framerate with three different render methods:

1) Normal, fully dynamic poly generation: 6FPS
2) Preloaded, attribute updated polygons: 6FPS
3) No polygon rendering, simply a "." output: 12FPS

So there is no distinct advantage to pre-loading versus dynamically creating polys. Moreover there are some negative effects of preloading polygons. The first and most obvious is that for some reason it adds a lengthy initialization time to the script - I'm not sure why it's doing that yet and it could possibly be eliminated. The other effect is a visual artifact that I don't believe there is a correct for: polygons are updated in "real time" on the display in front of the viewer. With the polygon visible and already existing in the DOM, a modification to its attributes results in the change becoming immediately visible to the user. This immediate update shows a rather unnatural sweeping painting effect around the display as each polygon is updated. With objects in motion it appears as if the objects are only loosely held together and could fall to tiny pieces at any moment. It's interesting, but definitely not appealing.

By contrast, the method I have been using for dynamic polygon creation bunches all the updates together into a single output variable and when the scene is completely rendered, the wnd.innerHTML is set to that output. this results in an effective frame buffering technique that updates all polys in the wnd simultaneously per frame. The effect then is all solid models remainting statically proportional and having a very "solid" appearance with smooth motion through the virtual space. Thus i believe dynamic polygon generation is still the way to go...

However an interesting factoid was revealed above as well: drawing no polygon at all merely doubled the frame rate. Before we started doing solid models with double-transformations, we could double that frame rate even still. So it would appear that there is still performance to be had in optimizing the transformation code. Hopefully merging the two transform functions together will make up for at least 50% of that difference.

-SK