[Verse-dev] using material node for audio

[Peter Lundén]

Emil Brink wrote:

>On Thu, 28 Apr 2005 12:56:19 +0200 (CEST)
>"Eskil Steenberg" <eskil at obsession.se> wrote:
>
>Heya. Great to see these issues being discussed, once again ...
>
>[...]
>  
>
>>>You should at least try to understand what im saying, I'm taking
>>>about that in the geometry fragmet there is a thing call layer_r, my
>>>idea was to use that to point to a layer in the current geometry
>>>node containing the data array.
>>>      
>>>
>>there isnt a "layer_r" unless you shoose to create it, "layer_r" is
>>just a name, why not name it what ever you want, how about "audio" or
>>"reflectancy".
>>    
>>
>
>From verse.h:
>
>typedef union {
>	[snip]
>	struct {
>		char layer_r[16];
>		char layer_g[16];
>		char layer_b[16];
>	} geometry;
>	[snip]
>} VMatFrag;
>
>I think this is what Peter was referring to. I'm not sure though, I'll
>leave this debate to you guys. His idea to use these three pointers to
>point at audio-specific layers seems totally right to me, together with
>the idea to use several material trees for to achieve the required
>number of bands/channels. I guess he didn't feel that was very pleasant
>to work with, though.
>
>  
>
Exactly what I was referring to, but now I found a problem with this 
hack, the layer would be associated to an object and not to the material 
as I would like. So now Im thinking of using the texture fragment 
instead, that would solve this problem. I know this is not the ultimate 
solution but it is a workable hack. The idea is to have all coefficient 
for one property in a single fragment graph.

As Lauri point out there are a number of possible representations of 
acoustic properties of materials and that there is one such 
representation that is used today for which you can get messured data of 
different materials. This representation is coefficients in a number of  
frequency bands and this is the form of data we have to live with for a 
long time i guess.

I dont think its the right way to use a complex graph structure when the 
data you have is inheritly an simple array of numbers and its in this 
form you will process the data. It would be extreamly clumpsy and stupid 
to have 96 copies of the same fragment graph, the only thing that will 
differ is the numerical data at the leafs, and you have no use of the 
graph structure itself, it is just a awkward way to store the array of 
numbers.

As I interpret it, fragments are a way to represent micro geometry, this 
is something we would not need in the audio domain at least for a very 
long time. It would be possible in theory to have micro geometry but 
there are no one, at least to my knowledge that is using that in any way 
for audio purpouses nor is there any known algorithms that can be 
applyed (please Lauri rigth me if im wrong). We are more intressted in 
simplifying the geometry rather the make it more complex. So the use of 
fragment graphs is not very intressting for audio, we just need a simple 
way to store our material data that is inherently an array of numbers.

If you think fragment also should be used to describe acoustic 
properties of materials there has to be some opening to make this 
possible or we need to make some workable hack to squeez in what we 
need. One such solution would be to have an unlimited number (but 
finite)  of channels in fragement. Then we can have a meaningful use of 
a fragment graph.

--PLu

>Regards,
>
>/Emil
>_______________________________________________
>Verse-dev mailing list
>Verse-dev at projects.blender.org
>http://projects.blender.org/mailman/listinfo/verse-dev
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: plu.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: not available
Url : http://projects.blender.org/mailman/private/verse-dev/attachments/20050428/ab408cbf/plu.vcf