Indigo Renderer Forum

Hi there.
I'm new to Indigo but already pretty impressed by it's capabilities!

Just two little questions concerning the current beta release:

1. It might sound stupid, but does Indigo actually care, in which order the XML elements are located in the scenescript? I strangly ran into some trouble here.

2. I couldn't find any documentation about how the new instancing function is implemented. Any hints?


Regards,
Sven

1) I think you need to define things (meshes, materials) before you use them. Inside compound tags (like material specifications) it probably reads all tags first and then applies them so order here doesnt matter (This is just educated guesses so I might be wrong)

2) Before instancing an object was COPIED into memory each time it was referenced i.e. not instanced. Now it only copies a reference (boundingbox + pointer) into memory. And no you dont have to do antyhing special to make it work. its under the hood.

Ah... ok, sorry. Seems like I completely misunderstood the term "Instancing".
I thought it meant to generate reproductions of a 3D object - e.g. by providing a number of different transform matrices, each generating a new instance.

Anyways, thanks for the fast reply!

Well in part you are right. Each instance can have a unique rotation and scale. So its possible to make 1000 different sized Bananas pointing in different direction with only a small cost in memory.

I just noticed there is an example for instancing in the new bunch of testscenes that came with release 07... should have taken a look into those a bit earlier...

However, why not have seperate scaling factors for x,y and z ?
How about putting all transforms into one single 4*4 matrix?
It would be more flexible and make the scene description more compact.
Like:

<instances>
<transform 4*4 matrix />
<transform 4*4 matrix />
<transform 4*4 matrix />
</instances>

I guess this "question" has been turning into a gentle "request"

Homogenous coordinates is not more compact. 16 numbers compared to 12

Also if i dont want a rotation matrix at all its MUCH more. Also people not familiar with homogenous coordinates will not understand anything.

Bad idea

Sorry but I have to disagree in certain points.

1. My example above replaces a whole <model> element with just one matrix. That IS more compact.

2. People who are not familiar with transform matrices won't understand a rotation matrix as well and we already got that.

3. Uniform scaling is boring for instancing. ;P

Uniform scaling? You mean when the maid has very small black and white panties?

Well you can omit the rotation matrix and then its more compact.

Seriously I think you could include both. thats the beauty of xml

I totally agree with you concerning the usability. Matrices are not too simple to understand for everyone, BUT: We're talking about instancing. Document parts defining instances are mostly not made for editing by hand.
Just an example: Think about a scene with 500... eh... bananas?
All slightly different in rotation, scaling and translation.
This would mean the XML document would contain 500 variations of the whole model element... a HUGE text file! Instead 500 lines, each holding a matrix would still be viewable.

well..those 500 matrix lines would still be "impossible" to edit manually won't they? I don't get it why do you need them to be viewable?

Suvakas

Just because of this its a moot point. IF a machine generates the data who cares if scale is separate from rotation? Make little Ono implement stuff that matters. Like more stable code on large scenes.

From my point of view it doesn't make sense to seperate transforms for instancing. And it's a real limit to only have uniform scale. Having it all in on complex matrix is just smarter and "better style".
But naturally every coder has different views on that and that's absoutely ok.

So clearly: These are only proposals I posting here.
I don't want make anyone to do anything.
And I guess Ono has serious reasons for implementing the instancing function as given - but this belongs to indigos internal code structure which I don't have any idea of.

... Though I'd love to have some answers on other topics...
Otherwise it's hard to develop anything for indigo just by guessing on certain fuctions or trial and error...