"james tittle" wrote:
On Dec 9, 2005, at 9:25 AM, Frank Barknecht wrote:
Hallo, chris clepper hat gesagt: // chris clepper wrote:
On 12/9/05, Frank Barknecht fbar@footils.org wrote:
[0] One line: http://www.epierre.ca/work/research/documents/ Representing%20Sound%20-%20Charlebois%20-%20Honours%20Thesis%20I.pdf
That paper is awesome. I think about 1/3 of it is just detailing the ways in which GEM sucks.
...yeh, interesting: how did you find out about it? Seems like it'd be nice to have a collected list of references to pd, gem, etc...
...as far as the "ways in which GEM sucks", it really only seems to point to two problems:
- the immediate mode of rendering vertices will not scale well:
this of course is solved to a certain extent thru the vertex_array branch, but that's not been incorporated into main cvs, sadly...at minimal, we should get in the vertex_tabread/tabwrite stuff, and the model loading into vertex arrays, since those are easy "wins" in speed
- there is no scene graph native to gem, so you have to write it
yourself in pd (hah! has anyone? ;-) ) Or, you could use something like gullibloon's osc server "gsrv" to control either their "gwiz" app, which is openscenegraph based, or fluxus, which has it's own scene graph; or...
Hey all,
Pierre and I have been working some time on more robust 3D rendering control from Pd. The spot_light was one of several quick additions that we needed for Gem to be usable.
It's funny that you mention the OpenSceneGraph (OSG) based approach, because in the end we gave up on Gem, and now we're building an engine using Pd & OSG. We find it much easier (and much more efficient) to build complicated scenes with this approach. A scene graph lets you organize your scene hierarchically with an object-based approach. You can send control messages from Pd to transform any node, and all child nodes are relatively transformed in a very efficient manner. There is great support in OSG for all the most popular 3D file formats, and coding new 3D algorithms in OSG is much easier because it's object-oriented, C++, and already has a lot of efficient 3D math to exploit.
Philosophically speaking, I'm not sure I understand why the Pd community would want such a low level approach to 3D rendering such as GEM provides. I suppose there might be those who want to have vertex-specific control, but that really doesn't harness the true power of Pd. The low-level vertex transformations should be programmed in C/C++, with appropriate functions to handle parameter changes from Pd. That way, you use Pd as the controller or interface between audio, 3D, and whatever else you want.
Anyway, we'll be publishing a bunch more stuff soon. I'll post to the list when that happens. And hopefully, we'll also have some code to add to Pd (when it becomes stable enough).
Cheers, Mike Wozniewski