Maxwell Render | Official public forum

insta crash when trying to use pretessellated displacement

anyone else suffering ?

It may still be related to RAM with pretesselated, even if it crashes before the Task Manager (and whatever it's called on OSX ) gets a chance to read the RAM usage. Try lowering the subdivision setting.

Damn thought I had sorted it , looks bugged to me . Just made a simple scene and on the fly starts very quickly and is eating up about 833.6mb of ram . I've set my subdivisions very low (2) to see what is going on. I soon as I try it pretessellated maxwell render insta crashes on launch.

Can anyone else confirm pretessellated is working for them ? (windows 8.1 64bit latest version maxwell 3.0.1.3 )

worked fine : windows 7 64bits ; maxwell 3.0.1.3

Thanks for checking Seg , well I'm a bit lost on it now. Think I'll post a simple scene to see if someone can spot my error.

here we are does this work for anyone else ?

I see, it's only applied to a triangle group. I don't think that's actually supported with pretesselated. That needs to tesselate the geometry as a whole, it can't just tesselate certain triangles of it. So if you want to just apply it to the top of that plane you have two choices:

- have two objects, so the top of it is a separate one
- arrange the UVs in such a way that the displacement for the edges/bottom have 50% grey in the displacement map you use meaning they won't move (in case you use the 0.5 offset parameter).

I will still note this as a bug though because it shouldn't just crash, but issue a warning.

Hey Mihai !

Thanks for the solutions ,I was sure I done it this way in the past ( 2.7.1 )must be my age catching up on me . On the fly working was throwing me that and the crash.

Anyway many thanks again !

best

Matt

Mihai wrote:I see, it's only applied to a triangle group. I don't think that's actually supported with pretesselated.
That needs to tesselate the geometry as a whole, it can't just tesselate certain triangles of it.

This frankly appears a bit odd to me. What's the reason that one can't accomplish with render-time subdivision what's nicely
doable in other fields of mesh manipulation? Triangle based subdivision of logical subgroups of contiguous meshes is the simplest
way but also quad based local subD (with a few boundary Ngons) is widely established.
Are additional triangles one would need on the seam of adjacent patches, when triangulating all items at render-time the reason
not to support local subD? In the way that one needed to remesh the whole item when applying an effect to just a partition of it?

Mihai -- I downloaded the file yesterday, but did not have time to comment until now. This crash looks to be a 3.0.1.1 regression; if you check it in 3.0.1.0, you should find it works fine, but that it crashes in 3.0.1.1 or 3.0.1.3 (testing on clean win7 x64 installs here, so I think seghier should check the integrity of his installation). As far as limitations go, if any triangle of a mesh uses a displacement material, then the whole mesh will be subdivided. In other words, it automatically works like your second suggestion.

photomg1 wrote: Just made a simple scene and on the fly starts very quickly and is eating up about 833.6mb of ram . I've set my subdivisions very low (2) to see what is going on.

Whether a number is low or high for subdivision depends on which Subdivision method is selected. The test scene is using catmull/loop, on an already fairly-dense mesh; subdiv=4 with catmull/loop on this mesh requires over 5GB, while with flat, it takes around subdiv=36 to reach a similar level of memory usage.

I see, I *thought* I heard it was supposed to work ok....

Hi JDHill ; i posted before Matt shared the scene ; i already heard it related to RAM ....

JDHill wrote:

photomg1 wrote: Just made a simple scene and on the fly starts very quickly and is eating up about 833.6mb of ram . I've set my subdivisions very low (2) to see what is going on.

Whether a number is low or high for subdivision depends on which Subdivision method is selected. The test scene is using catmull/loop, on an already fairly-dense mesh; subdiv=4 with catmull/loop on this mesh requires over 5GB, while with flat, it takes around subdiv=36 to reach a similar level of memory usage.

Yeah sorry about that it shouldn't have been on catmul loop , I'd made that seperate scene pretty quickly and I think displacement defaults to catmul loop?

Anyway at least I know now senility hasn't hit me yet and it did work in prior versions

JDHill wrote:This crash looks to be a 3.0.1.1 regression; if you check it in 3.0.1.0, you should find it works fine, but that it crashes in 3.0.1.1 or 3.0.1.3

I wonder if I'm having related problems with v3.0.1.3. I have a large render file that has five Referenced MXS files, all adding up to about 1GB. None of my materials use Displacement mapping but as it happens the Global Displacement setting in Maxwell Studio is set to ON, I didn't think this would matter since none of my materials use Displacement mapping.

My Windows 7 system has 32GB of ram and when I try to render this file with v3.0.1.3 the system ram usage quickly shoots up to 32GB and the render just sits there doing nothing. If I turn OFF the Global Displacement setting then my system ram usage goes up to about 6GB and the render proceeds as expected. Maxwell v2.7.20 doesn't have a problem with the same file even if the Global Displacement setting is turned ON.


Cheers,
Andrew.