From: Bernie R. <br...@ec...> - 2004-06-26 16:01:59
|
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 |