#IXP Light Locations
6 messages in this thread
Greetings,
We believe we know what causes the problem with LenzFX failing to track lights
with the flare utility when there is an AXP that uses secondary motion data.
The problem is not with LenzFX, exactly. It has nothing to do with secondary
data, per se.
Lights don't show up in the .LOC file. Therefore, we assume the only way to
track them is with camera/viewport data and the kxp_get_xform function. KXP
functions aren't guaranteed to work in the IXP, but they do, sort of,
sometimes. IF an AXP which constructs procedural faces in universal
coordinates runs at any frame concurrently with an IXP that attempts to use
kxp_get_xform, the KXP function call fails and thereafter returns constant,
erroneous values. Thus, the lensflare doesn't follow the light's motion.
Using lensflare is possible PRIOR to any calls to a universal coordinate
procedural face generator.
We've verified this using beta MAKE TRACKS, which creates universal coordinate
system faces, and it messes up our handy dandy light tracking test IXP.
-Eric Peterson
The guy that you want to make sure gets this information is David Thompson at
Digimation. He has picked up the torch for LenZFX and is now running with it.
Hi Lee,
Thanks for the info. We posted it so that anyone with an interest could see
it. It's important to us because it means that Particle Pack #2 and Make
Tracks are likewise incompatible with LenzFX 1' s flare utility. Could you
pass it along to anyone over there who needs to know? Thanks.
Get the manual yet?
-Eric
Hi Eric,
<<.. IF an AXP which constructs procedural faces in universal coordinates
runs at any frame concurrently with an IXP that attempts to use kxp_get_xform,
the KXP function call fails and thereafter returns constant, erroneous
values… >>
I'd love to get your AXP source code along with your *.3ds file that
accompanies this test to forward to QA.
Thanks for your diligence on this..
jonas[adesk]