hmmm...problem: building mesh KD-tree

[Tom.TNT]

Hi
I have big problem with this Scene:
http://www.tomtnt.maxarea.com/images/5-i2.rar

I use 3ds export - is faster then XML (woha-very very slow!)

My software configuration:
Max 8.0 + Indigo render 0.6 and plugin for max:M2I0.612
PC configuration:
Conroe 6400(@2,8) 3Gbram and Windows 2003 server SP1

Pleas help me!
this images is from Vray 1.5
http://www.tomtnt.maxarea.com/web/wip/0 ... deling.jpg
but i will rendered this scene in IDIGO!

sorry, my english is...jj, very bad

[Kosmokrator]

wow!!!

very nice scene man!i love it!
for your problem.....xxmm look to the procces taskbar and see how much memory uses indigo for the scene.....i think u may optimize your scene its polygon heavy...

[Tom.TNT]

hi
i can´t optimize this scene, because she has only cca 30% polygon on final scene...



this scene is now very very optimized...(505194 face) VS final scene from VRay has (cca 2 mil poly)!

Any idea?

[psor]

Heya Tom.TNT! ;o)

Well, as far as I can tell ... single objects with alot of polys are the
problem, not the whole scene polycount. I haven't had the time to
check at what kinda polycount indigo quits. Hope this'll help you to
investigate a bit more. ... btw. nice to have you here.

edit: I took a look at your scene and noticed that there are
a lot of objects, but non of them seem to have an ueber polycount,
so I guess my conclusion is not correct. It seems that Indigo has
a problem with the whole scene ... maybe I'll delete some of them
to see when Indigo starts to render ...

ps.: Thanks for sharing the scene. ;o)


take care
psor

[Tom.TNT]

HI
I create easy script for sorting object by facenumber. Now Itest my scene with this script.

http://www.tomtnt.maxarea.com/images/pr ... larray.rar

[psor]

Cool Tom.TNT! Thanx for the script, will be useful.


take care
psor

[Beltane]

I'm guessing that Indigo uses a surface area heuristic to build the kd-tree. From my experience, certain polygon configurations (especially those that contain interlocking or abnormally shaped triangles; for example, some of the intricate Jotero mathe models) can upset the partitioning algorithm. This results in split planes that overlap a large proportion of the triangles in each partition and thus leads to massive memory consumption. By and large, these bugs only occur in isolated cases and are difficult for the programmer to predict or debug.

I sometimes find that rotating troublesome models so they're slightly off-axis resets the SAH partitioning algorithm and allows the tree to build fine, without eating up all your memory.

Hope this helps!

[Tom.TNT]

hi,
i dont understand your advices, because you are probably not quite united. I would really enjoy the advice from the porgammer. I came to this conlusion after testing it in my scene - there are no error objects in the scene, but that error message depends on the polycount of the whole scene. I came to case that when I deleted few polys from anywhere, the render run right(cca250000polys). This conclusion was tested on another simple scene just with spheres, and it came the same result. I attached the scene to this mail. Just delet anyone sphere from this scene and it will work - it was tested on two different computers.

simple sphere scene - max 8.0 -http://www.tomtnt.maxarea.com/images/problemsolved.rar

Please, solve this bug, it would be really enjoyable!!
I think that the simliest way to solve this, would be on this scene.
Now Im testing export to XML. But unfortunately, the XML export is reaaaaally slow:(

last Vray render - first texturing - http://www.tomtnt.maxarea.com/web/wip/0 ... extury.jpg

[Tom.TNT]

hallo anybody

[Zom-B]

Hey Tom.TNT...

We are a mixed community, not everybody uses Max here, by uploding
your exported files EVERYBODY could take a look and help

After all Indigo got a Problem with the exported Scene, not with your original Max file...

The simple "Sphere Scene" exported would be great too, because its hopfully easier to overview!

P.S.
Like your work on your website very much!

[psor]

975308 tris in one object
i've had this before,
your mesh object is too large,
and indigo runs out of mem...

i also remember that .3ds is limitted to 64000 polys.
use xml embedded meshes instead, it's just so much better than crappy old .3ds...

try splitting up your object into several meshes.
it will also improve render times considerably cause of better use of the scene wide kd-tree (kd-tree of mesh tree's)

greetz,
radiance

Hmm, I've opened his scene and it is not one object, there are a lot
of objects and all of them have a "low" polycount. But maybe I don't
get it because I'm already tired and will soon hit the sack ... ;o))

So ... I did a lil test ...

316831 tris in one object, exported per .xml no problem


316831 tris in one object x3 per manual instancing


manual instancing in the .xml

Code: Select all

        <!-- Original Humvee Mesh -->
	<model>
		<pos>0 0 0</pos>
		<scale>0.01</scale>
		<normal_smoothing>true</normal_smoothing>
		<rotation>
			<matrix>
			1 0 0 0 1 0 0 0 1
			</matrix>
		</rotation>
		<mesh_name>humvee_01</mesh_name>
	</model>

        <!-- Instanced Humvee Mesh 01 -->
	<model>
		<pos>1 0 0</pos>
		<scale>0.01</scale>
		<normal_smoothing>true</normal_smoothing>
		<rotation>
			<matrix>
			1 0 0 0 1 0 0 0 1
			</matrix>
		</rotation>
		<mesh_name>humvee_01</mesh_name>
	</model>

        <!-- Instanced Humvee Mesh 02 -->
	<model>
		<pos>-1 0 0</pos>
		<scale>0.01</scale>
		<normal_smoothing>true</normal_smoothing>
		<rotation>
			<matrix>
			1 0 0 0 1 0 0 0 1
			</matrix>
		</rotation>
		<mesh_name>humvee_01</mesh_name>
	</model>

So what we need as a lil workaround and to get a better workflow,
is the native support of the exporters for instances. This would give
us at least a bit room to breath until Nick can get the code fixed.

I guess I should open up a new thread ... because I think that it is
not obvious that Indigo already supports instancing of objects.

Hehe, ... hopefully we can handle the beast. ^^


take care
psor