Inside Sabertooth
Learn how Sabertooth uses 3ds Max to create 3D interactive projects, including HBO Go’s Game of Thrones interactive experience
  • 1/3
You are here: Forum Home / Autodesk® Softimage® / ICE - Interactive Creative Environment / Instanced geometry = big problems?
  RSS 2.0 ATOM  

Instanced geometry = big problems?
Rate this thread
 
28896
 
Permlink of this thread  
avatar
  • Total Posts: 116
  • Joined: 19 February 2008 07:46 AM

I’ve had a couple of ICE scenes now where I’ve tried to use instanced geometry and in both cases I’ve had serious problems getting the scenes to render.

In the first case, XSI would render a few frames but seemed to not release all the ram after each frame was rendered, so the memory usage would climb and climb until I ran out of ram.

Now, I’m trying a batch render with a very simple ICE tree - a grid is emitting particles.  The particles are instances of a grid that has a front-back texture on it.  It’s only emitting 10 particles per second.  I can render the first 120-125 frames, then XSIBatch starts crashing.  Other machines in the render farm report they cannot write the rendered output.

I also have noticed that with these scenes my dual proc, quad core box renders with only 15% processor usage - so my dual dual core machine is significantly faster (it uses about 60% of the processors) - my single quad core machine uses about 30% of it’s proc while rendering these scenes.

I’ve already sent the scene in to tech support, but I’m curious if I’m the only one having problems with instanced geometry in ICE scenes.

Paul



Replies: 0
avatar
  • msasa
  • Posted: 30 August 2008 05:02 AM

Yes, I have this problem too



Replies: 0
avatar
  • rconover
  • Posted: 02 September 2008 04:44 AM

[quote=msasa;10161]Yes, I have this problem too

In previous versions of XSI you could hit issues if the instance geometry were too dense.
i.e. is this the ‘simplest possible grid’ is the instance object-or just one with ‘default’ settings (which might be too dense when multiplied with enough particles)?

Maybe the issue has gotten worse in v7? Or maybe its a mr 3.6 issue even…

I would love to hear what support tell you Paul…



Replies: 0
avatar
  • sfu_mocaw
  • Posted: 02 September 2008 06:18 AM

I’ve been rendering out some VERY simple ice instanced geometry and it’s been taking for ever to render- I thought it had more to do with using the get texture_map node and then routing that color back to the particles render tree...but maybe I’ve ran into the same issue as there are quite a few instances.

Does limiting the mr ram in the render options help? I’ll look into my own scene and see if my issue is similar or not...thanks for posting this though as I thought I might be doing something “really” wrong or just hitting a known wall.



Replies: 0
avatar
  • rconover
  • Posted: 02 September 2008 07:26 AM

Historically the instance render issue went from rendering and ‘nice and fast’ to ‘crashes’ with no more memory availble.

But ‘slow’ renders I would say would be something else. Instances themselves don’t have to render slow at all.



Replies: 0
avatar

seems that instances in ice are normal instances unless you
do something with instancetime, then they´re switched
to mr assemblies . if it´s a bigger character like the default
elefant and you emit only 20 of them (maybe 200000 tris)
then the system slows down like nothing.
xsi generates one file per char animated frame wich is
really big for that character , it has only 1,5 mb size
if you save it out normally. so loading seems to be the main
bottleneck ? and it´s really not very stable.
maybe a statement from halfdan would be nice if this
is going to be optimized ...

chris



Replies: 0
avatar
  • runejw
  • Posted: 07 September 2008 06:30 PM

I have a variation of the problem where the [B]Set Instanced Geometry[/B] function itself seems to be fairly unstable.

Situation: Made a simple grid emitter (standard 8x8, scaled up to 50x50 units) and initially cubes that flew off this in the Y direction.  Moved the camera around so cubes were flying towards the camera.

At this point my son pokes his head in and since he’s a big Star Wars fan we get the idea to replace the cubes with some spaceships.  Find some decent models on http://wolf359a.anet-stl.com/warmesh.html > use Accutrans 3D to convert to dotXSI format and import the Millennium falcon.  At this point I was positioned at the ICE Tree so the model imports to the ICE Tree -> unexpected error.
I discover this and move the model up to the Scene level and pick it -> still unexpected errors.  Delete polymesh for the Falcon, save and reopen with just points emitted-> same error message

So this indicates if you’re not paying attention and import a model into the ICE Tree, then the ICE tree may become corrupted for some reason…

Next (at this point my son left since my planned demo obviously fell flat on it’s face...) I try to make some scenes from scratch and use the Set Instanced Geometry with Explorer or via Picking.

[U]Conclusions from this testing[/U]:
You should make whatever you import into a Model and save that out to disk.
When this model is then imported and selected it works OK in simulation.  RAM usage seems to be a problem though - easily ran into “out of memory” errors. (32-bit XP SP3 with 4 GB RAM)

If selecting a complex Polymesh (imported dotXSI model) or similar for the instanced geometry then it usually doesn’t work and get “unexpected errors”.


So my question is what known limitations the “Set instanced geometry” compound has?

IMHO - ref for example the “flaming arrows” ICE tutorial then replacing particles with instances of some object should be among the prime uses of ICE and thus also very robust.  But the opposite seems to be the situation…



Replies: 0
avatar
  • rconover
  • Posted: 09 September 2008 03:27 AM

Maybe let XSI rebuild that imported geometry. Sounds pretty messy from here.

Do things like Merge (if multiple pieces) and/or extract polys and see if you can get those
results (maybe to a Freeze M of the result) to work.

If no go send it to Softimage support.



Replies: 0
avatar
  • runejw
  • Posted: 15 September 2008 09:02 AM

Success :)

Here’s what I did:
I converted the 3DS file to dotXSI
Imported it to XSI - ca 160K polygons and 65 clusters
Removed clusters, then did a poly reduction to around 80K that gave me this:
falconreducedno3.th.jpg

For fun I then subdivided it a couple of times up to 1.5 mill polys
falconsubdds5.th.jpg
...nah… too heavy (and some anomalies) so hit the minus key back.

Then made it a Model and exported it as a Model.

Then I tried to introduce a grid as emitter for ICE… but “unexpected failure” no matter what…

Started a new scene from scratch, this time made a cube for emitter with just particles and played that through. So far so good. Then imported the Falcon model. Hit CTRL-T and CTRL-G on it and renamed the group to “ShipGroup”. Then went to the ICE-tree and added the Set Instance Geometry to execute on emit. Explore > selected the ShipGroup and “Object and Children” also changed Instance Animation to “Do Not Change Instance Animation”

Set emitter speed to 10 per second. Hit play… a number of .1 size ships started to flow - with their backs first. Changed Orientation Angle to 180 to fix that. Increased size to 1 and upped to 20 per second then 50… still no crashes. 50 was too crowded so back to 20 and also an Add Forces node and Neighboring Particle Force to -.6 and falloff 7 to give a slight spread. Adjusted some lights, hid the cube and rendered:
falconinstancesnm0.th.jpg

So at least some confidence regained - that the architecture [I]can[/I] actually handle instancing of models with 80K polygons… BUT at the same time it seems sensitive to the workflow or the order in which things are done…



Replies: 0
avatar
  • f11
  • Posted: 27 April 2009 11:07 PM

so, instance geometry with ICE still a no go? or any fixes in 7.5?



Replies: 0