Indigo Renderer Forum

Hi all Hi Ono,

well still busy getting the beat wired to Blender and after you implemented
true instances i was wondering on how to do that with Blender..

with the max exporter it was not so hard to do..

i could translate, rotate and scale the instances on every axis
and the data was stored in the <model> matrix...

Now it seems we need orthogonal matrices and so the scale and
rotate will have to go out of the matrix to work ...

Why has this to be done... in my understanding now it is only possible
to translate instances but not rotate and scale on every axis...

maybe i still didn't quite get what an orthogonal matrix is ... so if all
of the above is still possible i would apprechiate some info
on how to "orthogonalize matices"..

cheers

u3dreal

There is a testscene and some infomation at nicks blog about instancing. (just in case you aren't aware)

I am having trouble understanding myself.

It appears from what I have read the only thing changing when an instance is posted is the position of the items with the scale and rotation staying the same.

Update: Maybe that is the purpose of it so far...you can still achieve good things without needing to scale and rotate. I suppose, that both of these features technically alter the mesh making it not an exact copy anymore which disables instancing.

Update 2: Just noticed you were able to do that in your other program. Now I am confused even more.

Just to say I'm very interested in instances rotation, would be a definitive solution to make realistic grass without the weight (get few clumps and rotate their instances around the vertical axis in a random fashion).

A must have.

Instancing works already !!!!
Just ALT-D dupplicate linked in blender that all objects uses same mesh, so mesh gets exported only once and indigo v0.7 do his job then
regards zuegs

CTZn wrote:Just to say I'm very interested in instances rotation, would be a definitive solution to make realistic grass without the weight (get few clumps and rotate their instances around the vertical axis in a random fashion).

A must have.

I think the only way to do this is to implement full ray<->object space transformation, which needs to be done for every single object/ray intersection test.

Code-wise it's very simple, but it's not necessarily cheap and is often difficult to retro-fit to an existing rendering architecture (e.g. if all the intersection code assumes unit-length ray direction vectors).

Ian.

An orthogonal matrix has unit length rows and all the rows are perpendicular to each other.
As far as indigo goes, it means that the rotation matrix must be *only* a rotation matrix, not a scaling matrix as well.

OnoSendai wrote:An orthogonal matrix has unit length rows and all the rows are perpendicular to each other.

That is called an orthonormal basis (or matrix). For an orthogonal basis it is not neccessary that the basis axis are unit length, just that the inner produxt is zero.

Actually an orthogonal matrix does imply unit length rows, and that the rows form an orthonormal basis.

OnoSendai wrote:Actually an orthogonal matrix does imply unit length rows, and that the rows form an orthonormal basis.

You are right, I didn't do my homework . An orthogonal matrix defines an orthonormal basis.

Ok so no more scaled ,deformed instances .. i like that ..

cheers

u3dreal

zuegs wrote:Instancing works already !!!!
Just ALT-D dupplicate linked in blender that all objects uses same mesh, so mesh gets exported only once and indigo v0.7 do his job then

It would be more useful, if the array modifier could be used for instancing...

IanT wrote:

CTZn wrote:Just to say I'm very interested in instances rotation, would be a definitive solution to make realistic grass without the weight (get few clumps and rotate their instances around the vertical axis in a random fashion).

A must have.

I think the only way to do this is to implement full ray<->object space transformation, which needs to be done for every single object/ray intersection test.

Code-wise it's very simple, but it's not necessarily cheap and is often difficult to retro-fit to an existing rendering architecture (e.g. if all the intersection code assumes unit-length ray direction vectors).

Ian.

Huh !? You mean it's hard for the engine to determine when a ray hits an instance with an arbitrary rotation, because its representation in space is different from the original (<- non rotated) ?

so... is there any way to make the matrices orthogonal?

further to my efforts with lego, i now have a blender scene with many shared meshes, and I can export these using instacing, but indigo fails because it says the rotation matrices are not orthogonal.

now, it makes perfect sense to be able to render lego with instancing - but for now i'm having to make everything "single user" as blender calls it (ie, a mesh for every single part - even identiacl ones)... which is a bit overkill and a waste of resources.

is it possible to knock up a script that can parse the XML and validate/correct the matrices?

perhaps this is a problem with the ldraw (lego model) _importer_ that i have though... there seems to be some funny business with materials too. are there any python heads here that would like to look at the code and see what's wrong? i don't know the firs thing about python or the blender API.

this is the importer i'm using.
http://web.mac.com/carstenm/iWeb/Lego/B ... A02E6.html
i did have to modify a path string in the script to make it work - anything more complex than that is a bit beyond me.

I have tried my 06 indigo scene (a beach house) in 07 and it gave me a rotation matrix error. (using blender and the 07 exporter with Zuegs rotation matrix fix) From what I remember it was a low quality door hinge made out of a cube stretched to a rectangle and copied to four areas that caused the error. I deleted these hinges and all is good.

I played with instancing, like Zuegs said further up in this thread, and all seems to work great.

I brought the blend file from about 18mb to 12mb so far, and that brought the xml from about 105mb to 75mb, and also of course helps Indigo take up less memory. I tried quickly last night some more instancing where I rotated and scaled some of the instances, it didn't give me any errors. It was too late to read the xml file to see how it was listed.

But anyway I thought I would post my findings here.