Hi everybody,
here are my $.02...
On Thu, 2005-06-30 at 22:48 +0200, Patrick Dähne wrote:
> Hello Allen,
>
> > The key changes were to:
> >
> > - Refactor the geometry data format used to not use any indexing.
> > Dirk tells me that multi-indexing can perform poorly and it just
> > makes it easier to implement...
>
> I do not like this because:
>
> - You loose information - the information that all vertices have the
> same normals, and that many vertices share texture coordinates. This
> information is not important for rendering, but it might be important
> for other algorithms working on the geometry.
True, you loose information there. But given that we're talking about
very specific geometry (i.e. text), I'm not sure what that information
would be used for.
> - You waste memory.
Again, true. But I haven't seen an application where that would have
been a critical problem, given that almost none of the apps use a lot of
text, and if you have 200 MB of geometry and 50 MB textures, 20K for
text are not a big deal.
> - Is multi-indexing really such a performance problem? Ok, OpenGL
> vertex arrays do not support multi-indexing, and OpenSG renders multi-
> indexed geometries without vertex arrays. But usually the geometry is
> written into a display list, and I do not believe that multi-indexing
> makes a difference when rendering display lists. But I have to admit
> that I never did performance measurements.
Probably not.
> Ok, these are not really strong arguments for multi-indexing, but I
> prefer to keep multi-indexing. (It took a lot of effort to develop
> that multi-index code ;-) .)
I can see that argument, but it's not really a very strong one.
Especially when thinking about the future, where multi-indexing is going
to be handled differently anyway. ;) In the interest of keeping things
simple, I'd say moving to non-indexed is ok.
> > - Added a method (addToGeom) that allows text to be added to an
> > existing text geometry node
>
> Good idea.
Yup.
> > - Added color data to the geometry to allow for colored text
>
> Ok. Adds some overhead to the geometry when you do not need the color.
That could be minimized by making it optional, as Johannes proposed. I'm
not so worried about the memory, as 4 bytes per color are not not a big
issue. I'm more worried about it overriding whatever color the Material
sets, if that has ColorMaterial active.
Yours
Dirk
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
