Viewport Optimization Methods

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 05 May 2013   #1
Viewport Optimization Methods

Hey there

So, Max has Adaptive Degradation, I don't know of any other methods(at least exposed methods), but I've recently learned that Maya actually uses Frustum Culling, which for me having a background in game development is a very natural and welcomed thing, so these are as far as I know the main methods of optimization the two software use, so how do these two compare and why hasn't frustum culling been implemented in Max?... I read somewhere that they've implemented a culling method for particles in the viewport(it's a module in pflow if I'm not mistaking), but nothing has been done about the viewport as a whole, then there is one scattering plug-in, CarbonScatter that has implemented this for their own plug-in, but that's as far as I know about this, any thoughts?
 
Old 05 May 2013   #2
It's not ideal, you're right. However, with every version of Max, the viewport gets faster, but often not in uniform ways - that is to say, I don't think it's a global culling method that they're altering (though perhaps they are, to an extent) but the major changes in viewport performance seem to happen on a per-object-type basis. You already mentioned particles, but they also have made huge strides in Spline viewport rendering efficiency, too.

Depending on the scene, we have a few techniques. One is a script that will take a selection and replace it with an xref object to an external proxy, whilst making the viewport version very low poly. For stuff that you need in the scene to be visible but don't constantly interact with, it's quite a good method, because it's there in the viewport at nice low resolution, but renders perfectly because it's just a proxy. (That's actually available on my website - the top script, if you're interested, but it doesn't sound like the sort of thing you're after, perhaps).
__________________

 
Old 05 May 2013   #3
Hey Dan, yes I'm familiar with proxies, and true, using them is a great way of putting some load off both GPU and memory, but they are a very general concept in that they are implemented in pretty much every package I've seen, the other thing is that they are implemented manually as in it's not a transparent operation done globally by the software itself like say Adaptive Degradation or Frustum Culling, the thing I'm curious the most about is why they haven't implemented culling in Max, combined with the current techniques it could be a great performance booster, unless it won't? and Max's viewport does not benefit from that method?

Also, and I know this is sort of on a very basic level what Adaptive Degradation is doing, which is dynamic LOD'ing, but isn't it possible to implement a true dynamic and automatic Level of Detailing mechanism inside of a DCC's viewport? so that the different LOD's for any given objects are created automatically and swaped in and out based on Camera distance?... I know this one is a bit ahead of time considering right now not even the game engines do this automatically, but I really doubt that this is impossible to develop in the year 2013...

PS: Thanks, I'll check out your script, should be useful.
 
Old 05 May 2013   #4
OT:
great scripts!!!
__________________
http://trideval.blogspot.com/
 
Old 05 May 2013   #5
Originally Posted by Rudiam: Hey Dan, yes I'm familiar with proxies, and true, using them is a great way of putting some load off both GPU and memory, but they are a very general concept in that they are implemented in pretty much every package I've seen, the other thing is that they are implemented manually as in it's not a transparent operation done globally by the software itself like say Adaptive Degradation or Frustum Culling, the thing I'm curious the most about is why they haven't implemented culling in Max, combined with the current techniques it could be a great performance booster, unless it won't? and Max's viewport does not benefit from that method?

Also, and I know this is sort of on a very basic level what Adaptive Degradation is doing, which is dynamic LOD'ing, but isn't it possible to implement a true dynamic and automatic Level of Detailing mechanism inside of a DCC's viewport? so that the different LOD's for any given objects are created automatically and swaped in and out based on Camera distance?... I know this one is a bit ahead of time considering right now not even the game engines do this automatically, but I really doubt that this is impossible to develop in the year 2013...

PS: Thanks, I'll check out your script, should be useful.


I'm not sure, it's an interesting idea. I've always found pro-optimiser to do a pretty good job of optimising geometry if you don't care about the topology, though it can take some time for higher polygon objects. I imagine any proposed solution like yours would have to involve some sort of pre-processing - sort of like how you need to do a render in order to bake light into a texture, likewise you may need to process the mesh's before they can then automatically LOD based on the camera position. Obviously this isn't ideal because it will need to do this every time you change the geometry. Perhaps this process could be made silent, to work in the background. I guess one difference is that in game engines, there's some sort of control over the "speed" of the camera in most senses. In a 3D viewport, you could go from being miles away from an object to right next to it in the click of a button, so the higher-poly LODS would either need to be constantly cached, or we'd need to expect a bit of pop-in whilst it loads it from somewhere in the file (or an external file, if the generated LODs were in separate files).

It's definitely an interesting concept and I'd love to see more exploration done into it. Have you looked into gPoly objects? It's a similar idea; It's a modifier that converts the mesh into a sort of GPU "native" format that sits on the GPU's own ram, so it runs a lot nicer. I've not got any experience of actually using it, however, and you need to manually select the geometry to wish this to happen to, so in that sense it isn't automatic.
__________________

 
Old 05 May 2013   #6
Originally Posted by DanGrover: I'm not sure, it's an interesting idea. I've always found pro-optimiser to do a pretty good job of optimising geometry if you don't care about the topology, though it can take some time for higher polygon objects. I imagine any proposed solution like yours would have to involve some sort of pre-processing - sort of like how you need to do a render in order to bake light into a texture, likewise you may need to process the mesh's before they can then automatically LOD based on the camera position. Obviously this isn't ideal because it will need to do this every time you change the geometry. Perhaps this process could be made silent, to work in the background. I guess one difference is that in game engines, there's some sort of control over the "speed" of the camera in most senses. In a 3D viewport, you could go from being miles away from an object to right next to it in the click of a button, so the higher-poly LODS would either need to be constantly cached, or we'd need to expect a bit of pop-in whilst it loads it from somewhere in the file (or an external file, if the generated LODs were in separate files).

It's definitely an interesting concept and I'd love to see more exploration done into it. Have you looked into gPoly objects? It's a similar idea; It's a modifier that converts the mesh into a sort of GPU "native" format that sits on the GPU's own ram, so it runs a lot nicer. I've not got any experience of actually using it, however, and you need to manually select the geometry to wish this to happen to, so in that sense it isn't automatic.


All valid points that you brought up, yes there would be a per-processing phase for the LOD generations, the decimation process could really use the same method pro-optimiser uses, since the topology isn't really important here, we only care about the approximation of the silhouette, and a great point about the object modifications resulting in regeneration process, but as you pointed out yourself , this could be implemented as an asynchronous and behind the scene operation so you would hardy sense the conversion, and again about the rate at which the distance changes is an interesting point, but the truth is that even though at a less perceivable rate, this issue still exists in many game engines and consequently games in which if you suddenly approach a model and based on your computer's resources you'd see the conversion happen right in front of you, but there are always optimization algorithms to mitigate these issues, and then of coarse is the issue of where to store all the different LOD's, embedded on the same file, externally referenced as in xref's and so on...

About the gPoly's, yes I know about them(funny, I had actually forgotten about them till now), I experimented with them a few times right when 2013 came out, on a very heavy mesh that was keyframed, and it did impact the playback's speed, quite dramatically, but I've never used them since, autodesk hasn't put a lot of effort into putting this out there...
 
Old 06 June 2013   #7
I'm pretty sure max does do frustum culling. If you have a very heavy scene but point the camera at only a very small section of it, the viewport is much faster. That'll be because stuff that's out of the frustum is culled. Or at least I've always assumed that's what it's doing. It is after all the most basic kind of view optimisation. If it didn't do this, then the overall frame rate would be the same regardless of what the camera could see.

What makes you think it doesn't do this?
 
Old 06 June 2013   #8
You can toggle the viewport statistics and zoom in a portion of your scene and you'll see that nothing happens to the number of faces/verts in the statistics, do the same in Maya and you'll see that the numbers change to show only the objects currently in the viewport, and also the fact that there's no indication of this feature being implemented in the help files... as I said before they've implemented a 'Camera Culling Operator' for the particle view but not for the viewport in general, so...

Edit: Actually I think you might be right, it seems kinda silly if this isn't implemented, the more I think about it the more I realize it can not, not be there, but then why the difference between the two programs, and why not mention a few words about this in the documentations?...

Last edited by Rudiam : 06 June 2013 at 11:42 PM.
 
Old 06 June 2013   #9
The scene statistics only show stats for the whole scene or the selected objects. They aren't much of a guide. It's not visible geometry that's in the view frustum (actually that wouldn't very useful to me if it was).

I'm not sure what Maya is doing, but it might be culling the off-screen nodes from evaluation. As far as I'm aware all objects in max that are visible (as in not hidden) are evaluated, whether they're on-screen or not (and before 2014 even if they were hidden). But that doesn't mean they aren't culled when it comes to drawing them. If they weren't, then as above it shouldn't make any significant difference to the frame rate what the camera is looking at. But it does.
 
Old 06 June 2013   #10
One odd thing I've noticed at times in 2014 - it may occur in other versions, I'm not sure - is that the viewport is actually far more responsive when you don't have Show Safe Frames selected. I don't know why, because this almost always makes MORE geometry visible, with safe frames cropping the view somewhat, and therefore culling more mesh - you would think. But not only is it not quicker, in my experience, but it's actively slower.
__________________

 
Old 06 June 2013   #11
Perhaps the additional clipping planes required are done in a slower way than viewport boundary ones. There might be a technical reason for that. I have no idea really. But yes it does seem to be slower.
 
Old 06 June 2013   #12
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 01:25 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.