Jeff Sonstein wrote:
> 
> > someone told me today that when making a multiuser vrml world its
> > best to keep it below 5,000 polygons, 10,000 at the max..
> > is this true?
> 
> don't know where they got those numbers from...
> my experience is that
> *all* VRML should be made with minimal polys
> but it has no specific effect upon MU
> 

 The problem with "minimal polys" as a measure is that the raw
number of polygons tends not to be the bottleneck on systems
where the 3d rendering is implemented in software (which is most
generic user systems right now)

 A couple of terms might help:

 "Geometry bound" refers to systems where calculating the positions
of each polygon is the slowdown.

 "Fill bound" refers to systems where the work to draw each
dot on the screen is what slows things down. (you're "fill-ing
in" the polygons from the geometry step, sort of like a coloring
book or a paint-by-numbers kit: the geometry step figures out
where all the boundaries go, and the fill step colors them in)

 A good rough test: Make your 3d window really small and check your
frames-per-second. Did making the window small help? If so, you're
fill-bound and reducing the number of polygons in the scene probably
won't help.

 The unfortunate thing about suggestions to reduce poly count is that
the obvious way to make a low-poly model look good is to add textures.
But on a fill-bound system, adding textures makes things even slower.
You would have been better off with a higher-poly model with no
textures. (Or maybe not, there are very few good rules, which is why
you've got to go try it out and see)

 Lest that sound discouraging: It's getting better all the time,
getting so much better all the time. Faster CPU's and (especially)
3D hardware mean that you can do really amazing things with VRML,
so if you can afford to spec your worlds to run in that type of
environment, you're going to have a lot of fun...


OBLIG VNET:

 You can force users to choose one of your models instead of using
their own by removing the "Custom" selection from the VNetInfo proto,
thus nicely sidestepping the issue of denial-of-service avatars...


-cks

Reply via email to