Re: Trimesh support (was: [Pyode-user] Initial (re)design questions)

[Bernie R. <br...@ec...>]

Matthias raises some good points.

Coming from a background of doing real-time 3D rendering in memory- and 
processor-limited environments,
I instinctively cringe at the thought of having the vertex and triangle 
data stored twice in two separate files.

However, as Matthias points out, there are advantages to doing so.  The 
most compelling is that the two
meshes may not be identical.

Still, I don't think we want to *require* users to use XODE whenever they 
have trimeshes, so I would want
us to support both XODE loading and direct passing of vertex/triangle data.

Thinking about this some more...

It occurs to me that the XODE implementor (hi, Timothy!) is faced with the 
double-to-float conversion issue
that we talked about d previously.  Since Python floats are in fact 
doubles, the XODE parser is effectively always
in double-precision mode.  We will need some way for the XODE parser to 
build an array of floats out of these
double-precision numbers in order to pass it to (a single-precision) PyODE.

In other words, two scenarios...

1) Someone has a graphics engine that provides vertices as strided arrays 
of single-precision numbers

     1a) they're using single-precision PyODE -- easy case

     1b) they're using double-precision PyODE -- they have to write some 
extra C code

2) Somone is writing a Python application (e.g. Timothy's XODE parser)

    2a) they're using double-precision PyODE -- easy case

    2b) they're using single-precision PyODE -- they need to do... something?

This is what brings me back to the "array" module in Python.  It already 
distinguishes between arrays of
floats (typecode 'f') and arrays of doubles (typecode 'd').

If someone is developing an application entirely in Python, or with the 
XODE loader, then they simply
build an array object using the appropriate typecode ('f' if they're using 
the single-precision PyODE or
'd' if they're using the double-precision PyODE).  If they're getting data 
from an engine, they will have
to copy the data into an array object (again using the appropriate typecode).

The use of array objects means that the single/double issue is extremely 
localized (just the typecode
of the array is different).  It also means that Python will handle the 
memory management of the array
for us, which is nice.  It also means that the vertex and triangle data is 
directly accessible from Python,
which may be handy in some cases.  And while it's true that we have to make 
a copy of the data that
the engine provides us, the fact is that we would probably have to do that 
anyway since most modern
engines use hardware vertex buffers that are not (efficiently) accessible 
from the application.

To summarize....

* XODE (or any Python application) builds a Python array object to 
represent the vertex data

* people interfacing to an engine do the same thing (probably entirely in 
Python, if the engine's Python
   interface already lets them read vertex data)

The only complication would be passing the array object through Pyrex and 
making it accessible
as a regular C array.  Matthias -- any thoughts on this?

I realize that I'm sort of rambling this morning, and waffling back and 
forth on how to do this.  I should probably
have read all the messages on the PyODE list first, then replied to them 
all at once in a more coherent way.

Oh well.  :-)




At 08:55 PM 6/25/2004 +0200, Matthias Baas wrote:
>Timothy Stranex wrote:
>>On Fri, 2004-06-25 at 02:31, brett hartshorn wrote:
>>>It would be nice to have some fast C functions that can convert ODE's 
>>>dReals vertices to osg's
>>>Vec3 vertices and pass that object directly to an osg geode.  These 
>>>functions could then be
>>>exposed to Python, then we would not have to do the conversion in Python 
>>>using tuples as the
>>>middle-man.  It sounds like its going to be hard, any ideas?
>>A function capable of doing that would need to know the internal
>>structure of the Python Geode class and the C++ Geode class. To do that,
>>PyODE would have the added dependencies of both PyOSG and OSG.
>
>In my opinion, we should keep PyODE free from additional dependencies. 
>This means the data has to be passed in a library independent way.
>
>While musing about the problem a bit I wondered if it's really that 
>essential to pass the data between a 3D engine and PyODE.
>"Where does the data come from?" I can also ask that question when looking 
>at the 3D engine which doesn't produce the data. I would say it's usually 
>a 3D modeller where the data is produced. So we rather need a way to read 
>the data produced from those modellers. And isn't that the reason why they 
>developed the XODE format? So having an XODE importer might probably be 
>more important than I thought in the beginning. I think the chances are 
>not that bad that there will be plugins for the most popular 3D packages 
>that can export XODE.
>
>Another point is, that I think it's not uncommon to have different meshes 
>for rendering and for collision detection. You want to keep the collision 
>meshes as simple as possible to get interactive rates whereas you want the 
>displayed mesh to be as "nice" and smooth as possible.
>It might even be the case that an entirely different representation is 
>used for rendering such as subdivision surfaces or NURBS patches.
>
>Well, I don't say a direct connection to a 3D engine wouldn't be 
>useful,  I only thought that there also has to be another way so we can 
>deal with the above points.
>
>- Matthias -
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self 
>defense, top technical experts, no vendor pitches, unmatched networking 
>opportunities. Visit www.blackhat.com
>_______________________________________________
>Pyode-user mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyode-user

--
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: br...@ec...   Voice: (519) 888-4567 x 2607 [work]
   URL: http://ece.uwaterloo.ca/~broehl