CGTalk > Software > Autodesk 3ds max
Login register
Thread Closed share thread « Previous Thread | Next Thread »  
 
Thread Tools Search this Thread Display Modes
Old 05-31-2013, 08:08 AM   #1
Rudiam
Expert
portfolio
maziar rud
Freelancer
Western Sahara
 
Join Date: Apr 2013
Posts: 327
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-31-2013, 10:00 AM   #2
DanGrover
Know-it-All
portfolio
Dan Grover
Technical Director
River Film
London, United Kingdom
 
Join Date: Sep 2004
Posts: 355
Send a message via MSN to DanGrover
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-31-2013, 11:03 AM   #3
Rudiam
Expert
portfolio
maziar rud
Freelancer
Western Sahara
 
Join Date: Apr 2013
Posts: 327
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-31-2013, 11:05 AM   #4
okmijun
Lord of the posts
 
okmijun's Avatar
portfolio
Zdravko Barisic
Architect
Belgrade, Serbia
 
Join Date: Jan 2005
Posts: 524
OT:
great scripts!!!
__________________
http://trideval.blogspot.com/
 
Old 05-31-2013, 11:29 AM   #5
DanGrover
Know-it-All
portfolio
Dan Grover
Technical Director
River Film
London, United Kingdom
 
Join Date: Sep 2004
Posts: 355
Send a message via MSN to DanGrover
Quote:
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-31-2013, 12:04 PM   #6
Rudiam
Expert
portfolio
maziar rud
Freelancer
Western Sahara
 
Join Date: Apr 2013
Posts: 327
Quote:
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-03-2013, 11:33 AM   #7
robinb
Expert
 
Join Date: Jul 2003
Posts: 2,908
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-03-2013, 11:00 PM   #8
Rudiam
Expert
portfolio
maziar rud
Freelancer
Western Sahara
 
Join Date: Apr 2013
Posts: 327
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-03-2013 at 11:42 PM.
 
Old 06-04-2013, 01:37 PM   #9
robinb
Expert
 
Join Date: Jul 2003
Posts: 2,908
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-04-2013, 02:04 PM   #10
DanGrover
Know-it-All
portfolio
Dan Grover
Technical Director
River Film
London, United Kingdom
 
Join Date: Sep 2004
Posts: 355
Send a message via MSN to DanGrover
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-04-2013, 04:54 PM   #11
robinb
Expert
 
Join Date: Jul 2003
Posts: 2,908
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-04-2013, 04:54 PM   #12
CGTalk Moderation
Lord of the posts
CGTalk Forum Leader
 
Join Date: Sep 2003
Posts: 1,066,481
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


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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 05:01 AM.


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