Dirk Reiners wrote:
Hi Marcus,
On Tue, 2005-09-06 at 13:53 +0200, Marcus Lindblom wrote:
>
See attached file for source code on the test (it's an extract from my
sources, thus lacking of includes and such stuff). I hope it'll be useful.
I've replaced our current intersect with, so I'd say that counts as a
yes. ;) I've also added your transform code. The build from dir and
points looked a little incomplete and didn't fit into our current API,
so I've left that our for now. Thanks for the fixes.
Neat! Yes, the build func is used only to construct a volume from
scratch (so I had to cut it loose from my code), so I was aware it would
not fit straight away. I rather figured you'd might use it later on, or
it would be useful for some other OpenSG user out there, someday.
P.S. W.r.t. some comments in osg::Line on handling of
infinite/semi-infinite/non-infinite lines, I think it should be split
into separate classes for Line, Ray and Segment, respectively. Makes it
easier to understand and reason about geometric code. Naturally, they
could all use a common parent class if deemed useful. (Updating CylVol
to use an Segment would then be a nice touch. :)
Do you really think you need separate classes for that? It might make
sense in the spirit of Pnt vs. Vec, I'm just a little weary about
implementation overhead and duplicated functionality. In theory most of
the internal stuff could use the infinite line, but then we need to
return two intersections and restrict ourselves to convex volumes.
That's probably not a big deal (I can't see many people wanting toroidal
bounding volumes ;), but something that needs thinking about.
Well, what I really wanted is the ability to express all those types
simple and efficiently. Having a single type and check their subtype
dynamically (by isFinite(), etc) does not really fit the spirit of a
statically typed language such as C++.
I'd like to have the ability to build geometric algorithms on top of
OpenSG, and a solid foundation of good classes is important. Whether
that matches your vision is another thing I suppose. :) (WildMagic is
_very_ nice in this area, but lacks in other places where instead OpenSG
excels, hence we chose OpenSG :)
/Marcus
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
