XML and Instancing

General questions about Indigo, the scene format, rendering etc...
j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

XML and Instancing

Post by j_07 » Thu Feb 15, 2007 2:01 am

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

Deus
Posts: 336
Joined: Sun Feb 04, 2007 3:47 am

Post by Deus » Thu Feb 15, 2007 2:50 am

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.

j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

Post by j_07 » Thu Feb 15, 2007 3:04 am

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!

Deus
Posts: 336
Joined: Sun Feb 04, 2007 3:47 am

Post by Deus » Thu Feb 15, 2007 4:42 am

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.

j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

Post by j_07 » Sat Feb 17, 2007 1:54 am

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... :wink:

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" :)

Deus
Posts: 336
Joined: Sun Feb 04, 2007 3:47 am

Post by Deus » Sat Feb 17, 2007 4:13 am

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 ;-)

j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

Post by j_07 » Sat Feb 17, 2007 4:43 am

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

Deus
Posts: 336
Joined: Sun Feb 04, 2007 3:47 am

Post by Deus » Sat Feb 17, 2007 5:18 am

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 ;-)

j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

Post by j_07 » Sat Feb 17, 2007 6:04 am

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.

User avatar
suvakas
3rd Place Winner
Posts: 2613
Joined: Mon Sep 04, 2006 11:08 pm
Location: Estonia
Contact:

Post by suvakas » Sat Feb 17, 2007 7:27 am

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

Deus
Posts: 336
Joined: Sun Feb 04, 2007 3:47 am

Post by Deus » Sun Feb 18, 2007 3:01 pm

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.

j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

Post by j_07 » Mon Feb 19, 2007 1:55 am

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.

j_07
Posts: 23
Joined: Thu Feb 15, 2007 1:45 am

Post by j_07 » Mon Feb 19, 2007 2:03 am

... 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...

Deus
Posts: 336
Joined: Sun Feb 04, 2007 3:47 am

Post by Deus » Mon Feb 19, 2007 2:05 am

:)
Last edited by Deus on Mon Feb 19, 2007 2:23 am, edited 1 time in total.

User avatar
manitwo
Posts: 1029
Joined: Wed Jul 05, 2006 4:50 am
Location: Tirol - Austria

Post by manitwo » Mon Feb 19, 2007 2:08 am

:?:

Post Reply
24 posts

Who is online

Users browsing this forum: Majestic-12 [Bot] and 46 guests