Hi folks, Its me again…I have some issues with cinema4d->dae->vvvv that I’ll try to explain here:
I’m exporting a simple dae model from c4d to vvvv (according to @evvvvil’s tutorial, dae1.4, renderer depthbuffer modified, etc…as always) but Im having some strange culling glitches:
I’ve made a simple cactus-like leaf from a spline and some bevel… but when I get it into vvvv its like the bevel seems glitchy… I’ve work around it modifying the culling but it also brings the problem about wich one is in top of wich…
I hope I’ve explained enough my problem… I’ve uploaded the c4d,dae and v4p files to dropbox.
thanks!
EDIT : deleting the zwrite node kinda solves it…but all the models become glitchy
If you view the normals in C4D you will see it’s already funky there. Probably you can tweak some of the parametric settings before converting to mesh to get a cleaner result. Even without the glitching a cleaner topology will also help a lot for lighting etc
Normals are perfectly fine - unless you have updated the files I’ve just downloaded - you would optimize the mesh, though - reducing “useless” points and polys.
Other than that, you could try to raise Camera _ Near Plane_ value: with 0.01 and unlinking zwrite and above, mesh looks fine.
basically what h99 said, see screenshot attached for a “fix”.
some more explanation:
zwrite doesn’t affect culling, it just messes up the sorting of your depthbuffer (which is your actual problem, will explain in a moment).
2-sided culling is also not needed, since the normals are fine.
what you see here is called z fighting, because your depth buffer has a limited resolution which you basically waste with the very far apart near and far clipping planes. it just doesn’t have as much precision anymore this way:
A 16bit depthbuffer for example will distinguish between 65536 different values which will be distributed over your visible area (called frustum, near- to farplane). If your frustum is too wide, positions will be too close to each other to be correctly resolved.
iirc, the depth buffer also has more precision close to the near plane, as it’s logarithmic.
