04 April 2013 | |
![]() |
|
Lard of the pots
portfolio
Joel Dubin
Creative Director
MadMicrobe
United States
|
Displacer deformer slow
So I haven't whined about anything this week so figured I'd better step up before the weeks over.
I use the displacer deformer for just about everything. Because it is so slow in the viewport, I've made it a habit of either making user data that controls all the deformers in a scene with a global on/off or otherwise I just filter it in the OM and uncheck them all. Wondering if there any why Maxon could get some more speed out of that deformer? I guess there are lots of calculations going on per frame to determine the correct displacement (??) but theres gotta be away to make it a bit more zippy. Unchecking object refresh helps in some cases but not all. I'll suggest to MAxon--but was curious if others notice this as well. |
04 April 2013 | |
![]() |
|
Meh
portfolio
Ferdinand
Germany
|
a skip (frames) option for the shader might help.
Last edited by littledevil : 04 April 2013 at 11:24 PM. |
04 April 2013 | |
![]() |
|
Scholar
noob
Amber,
Austria
|
![]() (to get extreme fast with displacer:
simply deactivate "object" inside the attributes of displacer in the refresh tab. ![]() edited: didn`t read your workaround. I saw in a video that the plugin "surfacespread", i think, is really fast in diplacing geometry. Maybe this could help you... Last edited by DesignAmyte : 04 April 2013 at 02:38 AM. |
04 April 2013 | |
![]() |
|
O_ō
portfolio
Ruben Artus Müller
Germany
|
What about doing the displacement through the material instead of a deformer?
|
04 April 2013 | |
![]() |
|
lover of gophers
portfolio
CGConnect Member
Kai Pedersen
Cg Supervisor
Image Engine
Vancouver,
Canada
|
not sure it could get a lot faster it is after all a single threaded process. I can handle a million polygons and tumble around, its laggy but doable. going beyond that they'd have to multithread I think.
__________________
Quote:
"Until you do what you believe in, how do you know whether you believe in it or not?" -Leo Tolstoy
Kai Pedersen |
04 April 2013 | |
![]() |
|
Developer
portfolio
Paul Everett
Developer
Beverungen,
Germany
|
There is an option (as decribed above) to turn off object updating.which basically stops the modifier asking all the shaders involved if anything changed.
I really dont think multithreading would make a great deal of difference to this modifier.Maybe a few % at best.Objects where never really inteanded to be driven by shaders, they are in two differernt worlds. So unless they rewite half the app I dont see much potential for improvment here. Last edited by tapaul : 04 April 2013 at 10:21 AM. |
04 April 2013 | |
![]() |
|
Lard of the pots
portfolio
Joel Dubin
Creative Director
MadMicrobe
United States
|
Thanks guys for the feedback
As I mentioned in my 1st post, yes, I'm aware that unchecking object refresh speeds things up...in most cases. I still find in shots with many such deformers, and in some case hierarchies with more than one dis. deformer, theres quite a bit of lag. I use this deformer a lot, find it an invaluable tool for a lot of the organic surfaces I need to create. I still find that I will need to switch off the deformer completely to get smooth editor playback, audio playback (without stuttering) or lag-free movement around my environment from the camera view. Editor playblasts might take several minutes longer with the deformer on compared to having them switched off. I'm sure there is a good reason why the slowdown is occurring. Maybe it's not possible for Maxon coders to achieve faster speedup of this deformer. Sure would be nice though. ![]() |
04 April 2013 | |
![]() |
|
lover of gophers
portfolio
CGConnect Member
Kai Pedersen
Cg Supervisor
Image Engine
Vancouver,
Canada
|
Originally Posted by JoelOtron:
I use this deformer a lot, find it an invaluable tool for a lot of the organic surfaces I need to create. I still find that I will need to switch off the deformer completely to get smooth editor playback, audio playback (without stuttering) or lag-free movement around my environment from the camera view. Editor playblasts might take several minutes longer with the deformer on compared to having them switched off.
Well in all fairness, if you were rendering true displacement you'd also be rendering much slower than without too. __________________
Quote:
"Until you do what you believe in, how do you know whether you believe in it or not?" -Leo Tolstoy
Kai Pedersen |
04 April 2013 | |
![]() |
|
Lard of the pots
portfolio
Joel Dubin
Creative Director
MadMicrobe
United States
|
Originally Posted by LucentDreams:
Well in all fairness, if you were rendering true displacement you'd also be rendering much slower than without too.
Of course--but we are talking about a deformer. Sounds like it is what it is and thats fine, was just hoping there was a way to speed it up. Guess there isn't--I can live with that. |
04 April 2013 | |
![]() |
|
Freelance Animator/Rigger
portfolio
Brian Horgan
Graphite9
Dublin,
Ireland
|
Why not put a Point Cache tag on the mesh, bake it and then delete/disable the deformer? Should make working in the scene a lot faster if it's not calculating all the time.
Cheers, Brian |
04 April 2013 | |
![]() |
|
Lard of the pots
portfolio
Joel Dubin
Creative Director
MadMicrobe
United States
|
I have thought about that Brian. On the average job there are a few dozen files that need updating/revsions along the way. Would be a lot of re-caching. Ideally it would just magically work how I want
![]() In some cases I have a deformer affecting hypernurbs that are at 0 subs in the editor but on render they are higher. Then that group is in another group with another deformer applied and another level of subs. In those cases caching would mean working with high res meshes which would even be slower to work with. Thanks |
04 April 2013 | |
![]() |
|
Expert
|
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 |
«
Previous Thread
|
Next Thread
»
|
|
|