IXP_EXIT
7 messages in this thread
If I create a 10 frame animation, and want to process all 10 frames through my
own IXP, does the IXP get loaded 10 times (once for each frame) such the
ClientStart and ClientProcImage (PHASE_START) are iterated once for each reload
of the IXP module, and I must therefore use IXP_EXIT when I amd done with each
frame.
–OR–
Does the IXP get loaded once, with one iteration of ClientStart, but 10
iterations of ClientProcImage (PHASE_START) and one closing IXP_EXIT when I
process the final frame.
I ask cause I cant figure out how to implement the 2nd way stated above. It
seems that I can only get 1 frame per load of the IXP, and that the IXP must
EXIT and reload for each frame, making it impossible to keep a file OPEN
between frames.
Hi Ken,
<< It seems that I can only get 1 frame per load of the IXP, and that the IXP
must EXIT and reload for each frame, making it impossible to keep a file OPEN
between frames. >>
I believe that 1 frame per load is the progrqamming model.. Remember, that your
routines should work in a network environment and with that model, you are only
guarenteed to be workinging on one frame at a time, unless the user selected
*.flc.
Have you checked out warp, vblur, stars.. in the eample files already?
jonas[adesk]
I have done more "experimenting" in areas un-defined by the IPAS manual, and
have determined that my IPAS IXP is remaining in memory between IXP_EXIT
returns. This was determined by creating some static variables which I write
out to a trace file.
Now I wonder, what is going on. On first load, my IXP gets into memory and
stays there until the 10 frame animation "video-post" is complete. Does it
stay there only because no other IPAS process is in the queue and would it be
bumped from memory if the video-post queue stacked 2 or more IPAS processes
onto each frame?
In the ClientGetState function, 3DS itself gets into which tends to imply that
3DS will at some time copy and/or write the state structure as a whole.
In my IXP I am able to determine that 3DS calls ClientGetState once for each
re-load of the IXP, which is once per frame of a 10 frame animation.
QUESTION: does 3DS at any time "over-write" the State structure with a copy of
the state structure maintained by 3DS independently of the IXP itself? If so,
does 3DS only do this when the IXP is distributed to a network multi-mode
operation, or does it also do it when the IXP is running only on a single
system?
Please send this to your developers:
On a single system operation, and my IXP is loaded at frame 1, what
circumstances would cause the IXP static variables to be lost? Although I have
an IXP which processes 10 frames of a test animation, I have noticed that the
static variables remain as though the module is never kicked out of memory,
which makes me suspect that an IXP remains in memory until the last frame, or
that if removed from "real" memory it is spooled to "virtual memory" and thus
always retains the statice vars between frames. But, since the 3DS docs do not
specify this issue, I want to know if and what conditions might cause the IXP
to be fully unloaded from memory and then reloaded between any frame x and x+1
on a single system.
Hi Ken,
:from the developers…
<< questions.. >>
Metaware 3.11@8 is what we build the toolkit libraries with. It works fine
with Metaware 3.11@9 and Metaware 3.2 although all of
these versions of the compiler have bugs in them that keep them from compiling
certain examples.
<< other questions.. >>
Whether IXP's get loaded and unloaded is at the discretion of 3D Studio. Do
not rely on variables being the same from frame
to frame.
What is Ken writing anyway? What kind of IXP needs to keep track of inter
frame state? Since he works for Xing, I'd guess its some kind of animation
file. If so, I'd stay away from IXP's and go to a BXP instead. Its much
cleaner and nicer that way.
I was working on an IXP cause version 3 could not run a BXP for animation
"output", and the Beta for 4.0 had no docs/text telling me that the BXP output
for animation was ready, so I thought (up till yesterday) that I had to "make
it work" using an IXP.
Now that I've been told clearly that the Beta version 4.0 will work with BXP
"output" I'll begin to convert into the BXP method.
Up until now I have been "emulating" the MPEG video output using a JPEG encoder
within the IXP, and used frame-to-frame progression for filenaming, and writing
of "trace strings" to a single file which was opened/closed for each frame.
BTW, I discovered why the dialog stuff was not going into my trace file.
I opened a file on the default path using open("trace.txt"…..); and just
found out last night that 3Ds was changing the path in the background and that
when the dialog was running the "trace.txt: file went into d:\3ds3\vpost, and
when the rendering was running the "trace.txt" file went into d:\3ds3\process.
I had been monitoring the output to the file in \process ans was unaware that a
separate file was created in \vpost. Once I discovered this I modified my code
to open a file as open ("d:\\3ds3\\trace.txt" …);
to force all output to the same path, then I finally got the trace info I
needed from the dialog handling.
Now I have discovered that 3DS default handling passes the dialog entries back
in a "batch" sequence AFTER the dialog is closed. I had thought the changed
parameters were sent back one-at-a-time as and when they were individually
changed on the dialog. NOT SO, but good to know, as I am loathe to assume
anything, but want to kwow "everything" about processing sequence and events
within the operation between my IPAS and 3DS