Hi,
playing around with Gem's spot_light I had a hard time to figure out, where the spotlight was looking until I found, that the cone used to visualise the light's position in "debug 1"-mode seems to point into a wrong direction. According to the screenshot in Pierre-Olivier Charlebois' thesis [0], the cone should point into the direction, the light is facing, however in my Gem (CVS couple weeks ago) it is pointing perpendicular to that. Attached patch should illustrate what I mean. Is this intended or do I just need new glasses? ;)
[0] One line: http://www.epierre.ca/work/research/documents/Representing%20Sound%20-%20Cha...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 12/9/05, Frank Barknecht fbar@footils.org wrote:
[0] One line: http://www.epierre.ca/work/research/documents/Representing%20Sound%20-%20Cha...
That paper is awesome. I think about 1/3 of it is just detailing the ways in which GEM sucks.
I haven't used spot_light myself so I don't really know how it is supposed to work. I think Ben Bogart may have posted that object?
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-%20Cha...
That paper is awesome. I think about 1/3 of it is just detailing the ways in which GEM sucks.
I haven't used spot_light myself so I don't really know how it is supposed to work. I think Ben Bogart may have posted that object?
The object itself is by Charlebois AFAIK. Ben then posted it here May 2005, however I think IOhannes did some changes when including it into Gem, like changing the inlet order, and maybe thereby the cone direction wasn't properly updated?
Anyway, it looks like a nice object, but it desperately needs a help file: I still haven't figured out how to use the rightmost inlet.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
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...
I haven't used spot_light myself so I don't really know how it is supposed to work. I think Ben Bogart may have posted that object?
The object itself is by Charlebois AFAIK. Ben then posted it here May 2005, however I think IOhannes did some changes when including it into Gem, like changing the inlet order, and maybe thereby the cone direction wasn't properly updated?
Anyway, it looks like a nice object, but it desperately needs a help file: I still haven't figured out how to use the rightmost inlet.
...I have a copy of the example & source file as it was originally
posted to the list, but I've never been able to get it work...haven't
had time to find out why, either :-( Anyway, here's what the inlets
are suppost to be:
right inlet: Color (ie. [1 1 1< )
middle inlet: linear attenuation; cone cutoff angle; decay at edges
(ie. [0.1 20 0< )
left inlet: gemstate
...kinda weird/messy to have those parameters lumped together, but
then I didn't write it ;-)
james
"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
Hallo, james tittle hat gesagt: // james tittle wrote:
...I have a copy of the example & source file as it was originally
posted to the list, but I've never been able to get it work...haven't
had time to find out why, either :-( Anyway, here's what the inlets
are suppost to be:right inlet: Color (ie. [1 1 1< ) middle inlet: linear attenuation; cone cutoff angle; decay at edges
(ie. [0.1 20 0< ) left inlet: gemstate...kinda weird/messy to have those parameters lumped together, but
then I didn't write it ;-)
Actually I have the same file as well, but it doesn't show any spot-light, even if you exchange the inlet order.
*However*: I now have a working patch, it's attached and was extended to also incorporate the attenuation/cutoff/decay messages. It works with current Gem-CVS, only the debug-cone is slightly wrong of course. It would be nice, if that cone would also display the cutoff-angle btw.
[spot_light] allows for some really nice effects btw, for example if you crank up the colors to "out of range" values like [2 3 0(, then it gives a surreal feel.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 9, 2005, at 11:19 AM, Frank Barknecht wrote:
*However*: I now have a working patch, it's attached and was extended to also incorporate the attenuation/cutoff/decay messages. It works with current Gem-CVS, only the debug-cone is slightly wrong of course. It would be nice, if that cone would also display the cutoff-angle btw.
...I've fixed the debug-cone problem: [spot_light] was initializing
to the wrong direction vector...also added checks to the light params
so that they don't cause gl to throw errors for out of range:
glerrors are silent, and at best just cause the calling function to
be ignored, but at worst they can screw up glstate and user
expectations...
...according to the spec:
linearAttenuation should be positive spotCutoff should be 0-90 or 180 ("special value") spotExponent should be 0-128
[spot_light] allows for some really nice effects btw, for example if you crank up the colors to "out of range" values like [2 3 0(, then it gives a surreal feel.
...yeh, neat kinda saturation along the edges...I've attached a
modified version of your help patch to work with the new, correct,
initial direction, and will commit it to cvs later when it's
prettified ;-)
james
Hallo James,
james tittle hat gesagt: // james tittle wrote:
...I've fixed the debug-cone problem: [spot_light] was initializing
to the wrong direction vector...also added checks to the light params
so that they don't cause gl to throw errors for out of range:
glerrors are silent, and at best just cause the calling function to
be ignored, but at worst they can screw up glstate and user
expectations...
Wonderful, thanks a lot! I won't be able to test today, but I will report back when I did in case of problems.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
chris clepper -
Frank Barknecht -
james tittle -
Mike Wozniewski