Is there any way to get time change callbacks working with “Make Preview Render”? I’ve done tests with rengisterTimeCallback and #preRenderFrame but it doesn’t seem either of them are working.
Thanks
The “Make Preview Render” does not invoke the renderer, so the #preRenderFrame callback will not be called. Interesting that the registerTimeCallback doesn’t work, as the slider is moving…
What is it you’re trying to accomplish?
it does indeed not signal the time change ‘callback’; how odd
that said – it does signal the #viewportChange callback, might be able to work with that
Figured something out, very cool! Thanks guys, helped a lot.
The #viewportChange callback wasn’t being called quite often enough, counted about 14 times in a 100 frame test render. Your suggestion though helped me notice the registerRedrawViewsCallback. I tried replacing my existing registerTimeCallback one of those and it seems to work like a charm both in viewport playback and the make preview render.
how odd… did every frame here… but then I tested in max5 -_-
max 5??? On a Intel x386 with the turbo button off ?
aw, come on… it’s a P1.6M and so forth… yes, it’s not quite a dual quad with 16GB of RAM and the latest space heater graphics card in it…
but let’s not go finger-pointing at irrelevant issues such as hardware and instead ask (within the context of making a preview):
- why does the time change callback not work when clearly the time is being changed?
- why does the viewportChange callback work in max5, but not in Max 2009? (yes, I checked)
Great that the viewport redraw callback works, though. Then again, maybe they’ll break that in 3ds max 2011 while we’ve moved on to 32-core beasts
( well, you guys, anyway… I might have that dual quad by then! )
So who do you want to blame? Kinetix, Discreet, or AutoDesk? I think the Yost Group is blameless for this bug… but not having any access to the lofting tool is all them…
I don’t know if it’s a bug – it might be a feature less / no callbacks when they’re not supposed to happen; after all, nothing actually changed in the ‘viewport’. The render preview window isn’t technically a ‘viewport’. Sure it uses the same display mechanisms as a viewport and such, but it’s not a viewport.
But by that reasoning, the view redraw callback shouldn’t get called either; hence, maybe they’ll ‘break’ (‘break’ doesn’t necessarily mean a bug) that in an upcoming version But perhaps then they’ll also add #prePreviewRender, #prePreViewRenderFrame, etc. callbacks