Fwd: vrml browsers

Greg Scallan ([email protected])
Thu, 1 Jun 1995 09:44:36 -0700


> Dear Daeron and the rest of the list. (Especially you browserbuilders) I have
> a problem with opengl. The problem is that on PCs opengl tends to be slow (100
> mhz p5 with 32 megs RAM) Now I do have a hardware accelerator for my Matrox
> impression plus. At Matrox they are saying that they want to support opengl at
> a future date however I should expect about 40k polys a seconf on that system.
> Using the rendermorphics library I would (according to rendermorphics!) be
> able to push 300k polys a sec (My pentium can benchmarked in C (haven't tried
> asm) only push about 200k polys a sec). With such differences it makes me
> wonder if it would be worth it to translate from opengl to rendermorphics
> specs on the fly and use that.

OpenGL, most likely, will be slower than alternative API's like RenderMorphics
on a given platform when it comes to a full software based implementation (like most
Windows based implementations). There is alot more functionality in OpenGL from a
traditional sense, but that may not make sense for a VRML browser.

The VRML spec is definitely tilted toward OpenGL. The Nodes are pretty much 1-1
mappings to OpenGL calls. Some Nodes will need additional code to be implemented in
RenderMorphics, but generaly not too much. The problem comes into play when you
need to specify things like different colors for ambient/diffuse/specular/emissive
properties of a material and the 3D API doesn't support that. OpenGL supports this,
RenderMorphics probably doesn't. Thus, if you can live without ever having this
type of functionality, you'd be ok to use rendermorphics. However, the fact that
rendermorphics does not support these types of calculations may point to some of the
reasons they are so much faster. Whatever you do, I would suggest writing to your
own 3D API independant layer so you could *plug in* OpenGL/RenderMorphics or
whatever 3D API you want. Which API is best is difficult to tell, and depends on
the application, the user, and the platform. Being flexible in this area is pretty
easy to do.

Greg

Greg Scallan
Paper Software
(914)679-2440
[email protected]