Re: vrml browsers

Syndesis Corporation ([email protected])
Thu, 01 Jun 1995 13:37:48 -0500


[email protected] writes:
>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.

No, this isn't a stupid question. Yes, VRML began as a subset of
Open Inventor's file format, and so far, the OpenGL makers and licensees
have jumped on the similarities and produced the first viewers.

I've often thought that the makers of fast low-end renderers would
have an advantage with VRML, as long as they had an effective parser.
Aside from the three-four very simple primitives in VRML (cube,
sphere, cone, cylinder, I think) it's simply polygon-based, and
of course you will render the primitives with polygons, too.

Yes, you don't need OpenGL; yes, someone could make a BRender /
RenderMorphics / RenderWare VRML browser. For that matter, those
companies are probably working on one right now, but are keeping
quiet about it. They would benefit from giving them away or bundling
them with accelerated graphics cards, in order to promote their
rendering technology APIs. Or for that matter, any alternative
fast polygon rendering code will do. One might argue that the
most common VRML viewers will not use OpenGL. OpenGL may be in WinNT,
but it's not shipped with straight Windows or Macs, which means someone
somewhere would be paying an OpenGL redistribution license if
your viewer depended on OpenGL.

The BR/RW/RM APIs will most likely be adapted for each common fast
video card for the PC. After all, they'll probably tap into the
acceleration at the same hooks that any OpenGL implementation
would, too. At worst, both OpenGL and RW/RM/BR would write to
bitmap buffers. At best, the APIs write to high-level rendering
functions implemented on-chip ala GLINT.

As an interesting note, the BR/RW/RM APIs let you choose the
internal math model, that is, you choose between link libraries
that use fixed-point or floating point in hardware or software.
In some environments, fixed point may have little advantage
over floating point. Perhaps they want to promote their new
hardware, but for example Apple does not have a version of
QuickDraw 3D for 680x0 Macs, it requires a PowerPC Mac,
and it doesn't use fixed-point.

And resolving the Mac fixed-point question, it does have both
16/16 fixed-point as a basic type, and in PICT files, you see
8/8 delta XY values, too.