#LenzFX problems
11 messages in this thread
I'm using digimation's lenzfx v. 1.3 It's really great but I'm having this
problem when my camera moves..the flares stays stationary even when the entire
enviroment and perspective's change!
For example, I have a flare on top of this post…I have a camera moving from
close view to far. As the animation goes…the flare moves OFF the post
(actually…it stays where it is in reference to frame 1… and the scene moves
) and the omni light I assigned it to is still on top of the post through out
the animation….never moved.Do you think the problem is in my version? …I
think at siggraph the current version is 1.3.1
I was just about to do a major render tonite…good thing I spotted this
error… Need help really bad.
Thanks
Erick, do you have any particle systems in your animation? LenZFX will not
work with any AXP that generates secondary motion data like Flame and Vapor..
Roy.
Thanks Roy that xplains a problem I've been having, whoops better turn of
vapor then!!
Greg 🙂
Glad I could help, I had the same problem when I first got LenzFX.
Roy.
Wait a minute. LenzFX is an IXP! How could it NOT work in conjunction with
particle AXPs that use secondary motion data? I mean, a bitmap's a bitmap,
right?
Sorry for the bother; this caught my eye because I'm scanning for solutions to
my own problems with LenzFX, and since we're creating particle AXPs I thought
we ought to explore it a little…
Eric Peterson
Sisyphus Software
>>Wait a minute. LenzFX is an IXP! How could it NOT work in conjunction with
particle AXPs that use secondary motion data? I mean, a bitmap's a bitmap,
right?<<
Eric,
The problem has to do with a particle systems secondary motion data. When a
AXP creates secondary motion data in the keyframer and passes that data to
VPOST it has a tendancy to cause lights to loose or forget their XY positional
coordinate data changes. Thats why the lensflare will sit in their original xy
pixel location during an animation when you use Flame or Vapor. Your lights
will illuminate the scene as normal, but their positional changes will not be
tracked. It's not a bug it's just a side affect of Particle systems.
Maybe we can get someone else to jump in here and give a technical explanation
of this side affect…Jonas ?
I would hope that MAX will take care of the problem. As it appears in the Press
release that all Plug-ins become an integral part of the scene.
Roy Baker…
Greetings,
Hmmmm…. You're right. We need a better technical answer. It doesn't
appear that the AXP 'sends secondary motion data' to video post. Basically,
the AXP simply takes the secondary motion data into account in the equations of
motion for the particles. It sounds as if putting particles into the scene
through an AXP using absolute coordinates may cause the 3DS.LOC file (the ASCII
summary Video Post outputs describing object position) to get corrupted or to
contain erroneous information. THAT would account for the LenzFX bug, since I
think it probably uses 3DS.LOC to find the lights…
Oh, Jonas…..?
-Eric Peterson
Hi Eric,
<< THAT would account for the LenzFX bug, since I think it probably uses
3DS.LOC to find the lights…>>
Have you verified this with any other non LenzFX IXP's?
jonas[adesk]
Greetings!
Good to have gotten to meet you guy! How's it going post-Siggraph?
Actually, I haven't been able to verify this yet since I'm experiencing my own
problems with LenzFX (I added more RAM and it stopped working), but Roy Baker
and the other person have been discussing it like it's old hat. From what I
can gather, the use of an AXP that puts procedural faces to the renderer in
world coordinates causes IXPs that track light positions to fail. I don't have
anything else that would let me test this, but it seems like the 3DS.LOC file
getting hosed would be the only thing to explain it. Roy said that using Flame
or Vapor, in his experience, had caused LenzFX to glitch – and that was exactly
the bug reported by the other person originally.
I only jumped in because Particle Pack #2 will work in world coordinates, and I
was wondering how the heck a particle AXP with secondary motion would mess up a
queued IXP…
Thanks
-Eric
Hi Eric,
<< I was wondering how the heck a particle AXP with secondary motion would
mess up a queued IXP…>>
Flame and Vapor use the Appdata chunk extensively. I'm not sure if Lenzfx is
parsing/using the Appdata chunk itself. Several developers have had to become
intimate with this data structure extension. Since I've never seen the code,
I'm not sure if this has anything to do with it at all.
jonas[adesk]
Greetings Once Again!
Thanks for your responses; I know you're busy.
I agree; multiple users of the appdata chunks of some objects could be the
culprit, but I don't think LenzFX/Flare has any reason to read the appdata
chunks of anything in particular since it has it's own settings saved with the
project file and its specific settings saved to its own configuration
directory. Once I get things squared away I'm going to experiment with this
and report back. OK?
-Eric