Collada camera node, view and perspective transformations fliped?

hi guys,

i’d like to use a camara animation and a bit of geometry out of a collada/.dae file in vvvv (animation and geometry were done in cinema4d). the import of everything via the collade nodes worked out of the box, nice! but unfortunately something seems to be wrong … because if i place now a “vvvv created geometry” in this whole setup let’s say a box node, then the box is somehow mirrored or fliped (green boxes) compared to the collada geometry (grey box in the centre). i tried to alter the coordinate systems in the ColladaFile node, but nothing helps … i am wondering now whether someone knows a workaround (or is it just a bug)?

anyway i did a testpatch, so you can check it.

any help is welcome. thanks!

benedikt

test patch collada cam transform problem (8.4 kB)

hi mr,

really just guessing:

-try to set the near clipping plane of the camera in c4d
-try changing the units you’re working with in c4d

before export *.dae, just make the size of exported object negative in Z = put-(minus) before Z
it flipps everything in XY, but when you open it in v4, everything will be all righthttps://vvvv.org/sites/default/files/imagecache/large/images/C4D.JPG

ah… why can’t all 3d programs keep their rotations correct…

(as DiMiX has stated,) different 3d progs use different orders of XYZ

eg. Z-depth is so-called because the Z axis disappears into the distance. 3DS-Max uses Z as it’s UP axis, whereas Lightwave uses Z as its DEPTH axis.

the problem stems from the translations from drawing board to computer program.

eg. 3DS-Max looks down on a drawing, whereas Lightwave looks into a drawing.

(thought i would give an explanation as this bugged the **** out of me when i was doing architectural stuff.)


check that
there is bug in loader, it sometimes flipped
changing RightHanded to LeftHanded and back normally helps

i guys,

many thanks for the replies!

i spent the whole morning trying all the tipps and hints. unfortunately i still have problems … it seems that it is somehow related to near clipping plane. i try to figure it out later in the week (have now other work to do) and come then hopefully back to you with a few insights.

so long.

have you also check z-writing/culling on objects, and backbuffer on renderer…

@ksp, yes checked z-writing/culling/buckbuffer … culling helps, now the meshes look correct. unfortunately the z-sorting of objects created in vvvv are somehow still contradict to the collada important ones. i think it is really a problem with the collade cam … because with the vvvv camera node everything is correctly displayed and sorted.

but i give up now :(

if someone wants to have a look … i prepared a zip with: cinema4d file, collada file, vvvv patch etc.

but many thanks for all the help!!

c4d to vvvv.zip (99.8 kB)

here looks OK

had a quick look at it and as you already mentioned it has to do with the clipping planes. i removed all the culling/zwrite tricks, and changed the near plane in the collada file from 0 to 100, rendering looks fine now. if you need a nearer clipping plane you need to use a depth buffer with a higher resolution or drawing artifacts will start to reappear.

see attached zip file, hope it helps.

c4d to vvvv.zip (98.3 kB)

hello elias, thanks for clearifing! now it works …

it seems my mistake was simply not to set the near clipping plane to something higher then 0. shame on me, such a newbie mistake.

for all the others … you can set the clipping planes in your .dae file via these parameters e.g.:

<znear>100</znear>
<zfar>4000</zfar>

Hi there,

I’m working on a project together with 3d artists, they use maya and c4d.
Unfortunately I don’t get any camera informations out of the collada files.
And it’s actually all about importing the 3d software camera movements from the 3d software to match the v4 animations to it…
So the cam move. ahs packed into the file by exporting the collada file somehow right? So far I can open the .dae file with both the collada and the assimp loader but if i connect the respective camera modules I just get a null as an output.

Can someone give some hints about the right export settings we have to choose inside the 3d software?

Any help very appreciated !

S

I don t know C4D or Maya but you can always assign an object to the camera and retrieve the animation of that object if you have problem retrieving the data of the camera itself.
S.

when you open the collada file in a text editor do you see any xml tags named “camera”? if not it’s cleary an export issue of the 3d software you’re using so you’ll probably have to ask for help there.
if you do find something called “camera” the issue might be ours. in that case it would be nice if you could post a stripped down example dae file which we can use to investigate.

tnx for the quick reply!
had a look to the xml and found out the problem was by export.

units centimeters(by export units settings as well!)
+
100
4000
+
collada 1.4

works fine so far out of c4d.

Ps: you may also want to remove the light obj. c4d places in the scene by default …

another question about the collada camera:

Is there a way to to get a quad fixed in front of the cam as you do with the softimage cam by feeding the inverse-transform module with the view projection output from the softimg.cam? I guess i should use the projection matrix output from the collada cam somehow… The aim is to use the camera animation fron the .dae file and still have some v4 generated 3d objects in the scene wich are not affected by the collada camera movement…

try the “Within…” group of nodes…

@antokhio, thanks for pointing that out, would never have seeked there.
Any idea why the Z axis can’t be inverted there?

Wouldn’t it be quite coherent if the collada-node had a Transform In and thus allow for daisy chaining of the transforms? I tried to swap the order of transformations using *-(Transform), but didn’t get the desired result.
Right now, i have to do
group > scale z=-1 > unparent > freeze transformations
with everything i’m going to export (from Maya) to collada for vvvv, which is i bit of a hassle.