[PD] Bug in spot_light?

[Mike Wozniewski]

"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 at 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:
>
> 1) 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
>
> 2) 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