>> I would be grateful if anyone could tell if there any other general
>> techniques for making VRML go faster that wouldn't be involve too much
Get a good 3-D card; and either turn "collision testing" off or use proxy
statements to simplify the collsion testing. This will do a _lot_ for the
A warning though: WorldView's proxy testing is totally worthless, pure
bug-bait; Cosmo's proxy testing is (according to their bug notes) crippled
but still somewhat useful.
>No, I don't believe so. However you can limit the hassle with good
>planning (just like with anything else).
>PLANNING FOR SPEED
>Keywords: LOD, Script, VisibilitySensor (*Sensor),
>Billboard, NavigationInfo, Illusions.
You missed "anchors" - speed the world by subdividing it into a set of
smaller worlds and then jump between them with anchor statements and
mouseclicks. This is definitely a low-hassle method.
>An underestimated use is for example on ElevationGrids.
>Instead of having one giant, use several small once and LOD them.
Interesting! You use Cosmo, right? This method didn't help me much when I
tried it since the memory load for elevation grids is, typically very large.
Actually, the browser need only do a 130x130 grid, more or less, to meet the
spec. blaxxun is the only browser I've tried that Transforms large grids
quickly. (Regarding grids: Cosmo is ok, and WorldView should be taken
behind the barn and shot.) So the speed issue took a backseat to memory
usage when I tried this method with WorldView.
>are also (more content related really) some nice tricks you can do with
>LODs to make special effects, but that's another story.
>Script: ECMA vs Java. This is something that recently have been
>confirmed can make a big difference.
ECMA? Hmmm... I tried this a few months back, with Cosmo, and it wouldn't
lines). ECMA (which I extracted from the spec. on the web) simply didn't
> When to use it though isn't really
>clear to me yet, so I leave it up to others to answer. Also there are
>some parameters like directOutput and mustEvaluate that you should
>carefully study. Use scripts together with sensors to turn stuff on and
>off when you don't need it.
Yep, and keep the scripts simple. A script that tests a series of buttons,
for example, can get surpisingly slow and, more importantly, the interrupts
can create jerky motion.
>A field you should always start with when
>you make a new Script is the "enabled" field. Always give the
>opportunity to turn a script off when it isn't needed.
>VisibilitySensor (*Sensor): Sensors have to evaluate every frame (just
>like anything else) and if don't need a sensor active be sure to turn it
>off. An example is to have a VisibillitySensor turn on a Proximity |
>Touch Sensor which in its turn triggers a TimeSensor. Then it is only
>active when you really can use it. Warning on the Proxysensor though,
>because you might get into trouble when you "back" into one that is
>controlled by a VisiblitiySensor.
Hey, thanks again!
>Billboard: This really should be under the "illusions" keyword. However
>it's so useful I thought I'd give it its own section. Billboards are
>very good to you if you are working with round shapes on long distance
>(not necessarily long).
"round shapes"? Could you elaborate this please?
> I don't think you need a great imagination to
>understand the difference of doing a full scale tree (where I found
>Billboards most widely used) instead of having a single polygon (feel
>free to triangulate it also) with a texture on it. Another nice way of
>using billboards is of course for signs, but that's another story.
Be sure to use a graphic with transparency to color the tree; otherwise the
spaces between the brances are (typically) gray which, frankly, looks dorky.
>NavigationInfo: You asked about pixel doubling. Now, we don't have that
>in VRML in the same way Doom and the alike have. Some would call pixel
>doubling cheating, I would call it product specific (meaning I would
>like have that possibility). VRML is a general file format for 3D on the
>web. So, what has this to do with NavigationInfo? Well, very little, but
>you have a field in there called visibilityLimit which you can use to
>limit how far you see. However the line "Geometry beyond the
>visibilityLimit may not be rendered." to me could mean anything.
>Illusions: This is for me where VRML stands today. If you are developing
>for Internet and don't know what hardware your visitors use you really
>have to work on this skill.
You also need to know the browser your visitors are using. If it isn't
Cosmo then lock the door.
Incidentally, WorldView defines colors in a non-standard way so nothing
looks the same there as when viewed with Cosmo. Cycling through a range of
colors for an object gives very funky results unless the colors are very
carefully chosen (with WorldView). And blaxxun browser loads image files
onto elevation grids erroneously: images that work with Cosmo and WV will
look flipped (around the Z axis, I think) with blaxxun. Blaxxun doesn't
color grids properly either in my experience. And WV doesn't (and won't)
implement the "gravity" option. Both Cosmo and WV fail to display objects
with a size of zero, and present error messages instead, even though this is
completely legal according to the copy of the vrml spec. I checked. (The
original version of WV does implement this though, but this excellent way of
displaying or hiding objects in a scene is now unavailable with WV.) Etc.
Actually, if you want your special effects to work in several different
browsers, you will have to use a fairly small subset of vrml. Very limited
set, really, when you also accomodate the various differences at the coding
level (like the proxy question).
Since browsers can be loaded quite easily, it's better to require visitors
to use the browser you've chosen. Otherwise a lot of them will be unhappy
no matter what you do.
Just as the above tree example things are
>best done in low-poly or with some tricks. This is unfortunently
>something that is pretty hard to learn from tutorials (I've always
>wanted to write one about it) since there aren't exactly any about it.
>Illusions is often what makes one world different to another. No
>compression utility I know of can compress your world as much as you can
>do with a little creativity.
>Illusions doesn't need to mean that you can't do hi-poly objects. The
>two keywords mostly connected in this mail are in my opinion LODs and
>illusions. The reason should be fairly obvious - LODs create illusions.
>You can build very big worlds (like game scenes) if you use LODs wise
>without for that reason giving up on the details.
There's a catch to LODs; two actually.
First, the distance from the viewpoint to the LOD center is radial (i.e.,
activation occurs in a circular or spherical region; unfortunately, vrml
primative shapes don't include circles and rooms, etc., are typically
rectangular anyway. So you have to include the adjacent rooms at high res.
when the occupied room is in that LOD state. This gets pricey.
Second, the activating distance is variable by default (the browser sets it)
and setting these by hand, to avoid weird jumping scenery. Hand-definition
of these distances is a chore. And some slack should be included in the
system as you write it because the new level won't load until after the old
one is removed (with WV anyway, in my experience).
>Of course this isn't where it all ends. I've saved the best (nerdiest)
>tips for last. Use a very slow PC when you develop and do it by hand :)
Of course, using a slow PC can prevent you from using the techniques that
give the _right_ results. So this decision is a judgement-call situation.
>Use modelers only for geometry creation and always run them trough some
>sort of optimizer before you use it. Get to know your optimizers! Re
>slow PC. At least preview it on a slow PC before going public with it.
Can you recommend an optimizer?
Actually, forcing computer owners to buy better hardware is a
well-established and respected part of the software business. People who
can't afford better hardware don't have money to spend on your software
anyway; and if _everyone's_ programs ran quickly then wealthy people would
have one less reason to gloat and, frankly, the industry would crash like a
pregnant woman on skates.
>A final note about speed vs speed vs detail.
>One of the worlds (yeah, ForestWorld) I've created has a lot of hits on
>it. Thousands of people have seen it and I got a lot of feedback on it.
>I don't believe that the reason for this is that it's nicer than others
>stuff it's just that it's a pretty big world (no real interaction) that
>people actually CAN SEE and experience. It's very fast to download
>(since it's more or less build by scripts) and it's very fast to render
>(since I did a lot of planning for it). The point I'm trying to make
>(can never be said enough) is that if you don't make it small nobody
>will see it, and why publish it if you don't want people to see it?
Neat! Can we have the code, or will we have to "steal" it? (Hey, just
The part about building it from scripts, to speed download, sounds nifty
though. Care to expand on that?
>Niclas Olofsson Ume? University, Sweden
>Pedagoggr?nd 1A-210 Student, Dep. of Computing Science
>"En seglare ber inte om medvind, han l?r sig
read more »