Re: Implementing Browsers
Nathan J. Strange ([email protected])
Sat, 03 Jun 95 01:03:31 +0000
> Problem 1: Non-convex faces=0D
As a browser writer, I *do* sympathise with your position but the alterna=
tive to allowing non-convex =0D
=FFfaces is to put the burden of decomposition onto the authoring tools a=
nd settle for (perhaps =0D
=FFsignificantly) larger VRML files.=0D
=0D
Much though I do not relish the task, I think that in terms of performanc=
e hits, it should be a =0D
=FFbrowser's responsibility to render what it "sees". If this includes no=
n-convex facets then so be it.=0D
=0D
As a general pointer, whilst much of what you say regarding renderers' ab=
ilities is true, it would =0D
=FF*always* be prudent for a browser developer to build his/her own layer=
of code between the VRML =0D
=FFparser and the rendering library. This aids portability in the long ru=
n and provides an ideal =0D
=FFrepository for facet decomposition amongst other things.=0D
=0D
=0D
> Problem #2: 4x4 modeling transforms=0D
> If your coordinate system doesn't happen to match Inventor's,=0D
=0D
AIUI the coordinate system is part of the VRML spec. and nothing to do wi=
th Inventor.=0D
=0D
However, you make an interesting point regarding 4x4 matrices, ARE there =
any transforms which =0D
=FFrequire 4x4?=0D
Also, what was the original intention of the MatrixTransform node type si=
nce it does seem redundant =0D
=FFgiven the existence of Transform node=0D
=0D
=0D
=0D
> Problem #3: Scene graphs=0D
> Almost all the renderers out there have some notion of hierachical=0D
> collections of objects; in fact, I suspect many of them do it in remark=
ably=0D
> similar ways. However, so far as I know, *none* of them implement a=0D=
> "scene graph" in the same way that Inventor does.=0D
[...cut...]=0D
> The (potential) problem arises when we start discussing behaviours.=0D
> A lot of the discussion of behaviours has centered around=0D
> "modifying the scene graph"; the problem is that there's absolutely=0D
> no guarantee that there *is* a "scene graph" as such. For example,=0D
> individual transform nodes will probably have been accumulated into a s=
ingle=0D
> matrix for each object; if a behaviour tries to update just one transfo=
rm=0D
> node, it won't be able to (the information isn't independently availabl=
e).=0D
=0D
=0D
Excellent point. However there must be some mechanism whereby VRML can co=
mmunicate an object =0D
=FFhierarchy to the browser. In the absence of a better thought out mecha=
nism I think that we should =0D
=FFaccept that browsers must maintain the object hierarchy. Of course thi=
s may all change once we start =0D
=FFtalking about behaviour....=0D
=0D
=0D
+--------------------------------+-----------------------------+=0D
=A6 Dave Durbin =A6 [email protected] =A6=0D=
=A6 Visual Systems Solutions Ltd. =A6 100102,[email protected] =A6=0D=
=A6 Who ? =A6 [email protected] =A6=0D=
+--------------------------------+-----------------------------+=0D