PDA

View Full Version : Help to determine Lightwave bug



peebeearr
11-21-2018, 02:43 AM
I have submitted a bug that I found in Lightwave. Originally I needed to solve an issue I had keeping an object from an object sequence in the middle of a camera no matter the size of the object. I have posted up a thread about that here:
https://forums.newtek.com/showthread.php?156677-How-te-keep-camera-in-the-moddle-of-an-object

I did get it to work but in the process I found, what I think is, a bug in Lightwave. Whenever the object changes the nodal modifier analyses the height of a part in that model and displaces a Null so the camera (attached to the Null) moves exactly into the middle of the object. This all looks fine in Layout. As soon as the new model is loaded from the sequence list, you can see the nodal modifier changing the position of the camera....

Now here comes the bug.... when rendering, it seems that the displacement is not 'picked up' quick enough. The first frame of the replaced object has an old position. The rest of the frames have the correct position of the camera. This ONLY happens when you make a Preview or render a sequence with <F10>. If you scroll manually in Layout, you can see the camera offsetting quickly just when the object is loaded and if you would do an <F9> all is ok....

I have submitted a bug report but Support is unable to see the error occurring... I have tried with all 2018 versions and on my comp it happens all the time. Could you guys do a test for me and render the little sequence in the attached scene and report back if frame 40 (the red block) is offset to frame 41 and onward?

Cheers,

Arthur
143394

jwiede
11-21-2018, 01:13 PM
You need to repackage (and re-archive) the scene using only relative paths, there are a bunch of absolute path references in the scene, buffer output directories, etc. that will prevent it from working for most testers (esp. folks on non-Windows systems). Even the object replacement list itself is making unsafe assumptions about the name of the content directory (if testers just de-archive from the archive into a dir of the same name, "Object-replacement-issue-Scene2", the object replacement list file no longer works).

Please fix these issues, and I'd be happy to test. I tried fixing them here, but without a working scene as a starting point (here basically all directory references are broken), repackaging as needed is difficult.

peebeearr
11-21-2018, 07:09 PM
You need to repackage (and re-archive) the scene using only relative paths, there are a bunch of absolute path references in the scene, buffer output directories, etc. that will prevent it from working for most testers (esp. folks on non-Windows systems). Even the object replacement list itself is making unsafe assumptions about the name of the content directory (if testers just de-archive from the archive into a dir of the same name, "Object-replacement-issue-Scene2", the object replacement list file no longer works).

Please fix these issues, and I'd be happy to test. I tried fixing them here, but without a working scene as a starting point (here basically all directory references are broken), repackaging as needed is difficult.

Hi John,

I have no idea how to do what you are asking me... I checked the scene file and the loading of the object files are relative:

LoadObjectLayer 1 10000000 ../Object-replacement-issue/Objects/blue-box.lwo

As for the buffers... I cannot change that to a relative path. Everything is linked to the content directory?
I use the 'Use Preferences Output Path' in the Output tab of the Render Properties so when you change the content path (because the whole structure has been moved to a new location) all you need to do is adjust the Content Directory, which Lightwave will ask for if it detects your loading a scene from a different directory than before.

But for this example scene you could even ignore the buffers as the bug will show itself in a simple Preview from within Layout as well.

Also the Object replacement list has to be relative paths otherwise you would constantly have to change that text file. Although the manual says to use a Full Patch, underneath notation works like a charm for me and moving the content folder around would not work if I would have used full (hard) paths.

#LW Object Replacement List
0
..\Object-replacement-issue\Objects\blue-box.lwo
40
..\Object-replacement-issue\Objects\red-box.lwo
80
..\Object-replacement-issue\Objects\yellow-box.lwo


Anyway, I have tried 'Package Scene' but that really screws things up especialy because I use a replacement list... the packaging script only sees 1 object at the time as it does not take into account the object sequence list:(... As long as you preserve the content structure in the zip it should work. But then again, I can only test on a Windows system.


What I did do is added the root folder to the zip (see new attached scene file). Just unpack the zip file to any location on your harddrive. You should end up with the following structure:


Object-replacement-issue\



../
ImageCache


../
Nodes


../
Object-Replacement


../
Objects


../
Renders


../
Scenes



Then in Layout make sure you have 'Auto Detect' checked in Preferences (<o>) and load the scene file. Now Layout will ask you if you would like to change the content directory to wherever you have out the structure above and voila, all works... At least that is how it works on my system. Even after removing all old references to my original project folder (G:\\4. Projects\\2018006_APC-Rendering.... etc) I did not get any nag screen and a sequence render (<F10>) put all the renders nicely into the Renders folder under the above structure, wherever I put it....

So please try the new scene file attached.

Cheers
143397

Edit:
John, I know now why the object replacement would not work... That's because the correct named root folder was missing... In the new ZIP file that should be fixed.

jwiede
11-22-2018, 11:32 AM
Well, I'm not quite sure what's going on, it's possible that Object List plugin simply doesn't work at ALL on Mac. No matter what the object list says, I never see blue-box.lwo get replaced by either red-box.lwo or yellow-box.lwo here. I've filed a bug on Object List apparently doing nothing on Mac Layout (LWB-4477), and suggest you file a bug on yours as well.

peebeearr
11-22-2018, 06:22 PM
Well, I'm not quite sure what's going on, it's possible that Object List plugin simply doesn't work at ALL on Mac. No matter what the object list says, I never see blue-box.lwo get replaced by either red-box.lwo or yellow-box.lwo here. I've filed a bug on Object List apparently doing nothing on Mac Layout (LWB-4477), and suggest you file a bug on yours as well.

Oh thats pretty crap too :-(
The bug/issue I'm experiencing has been lodged long time ago (LWB-3944) and is currently being investigated by Newtek. BUT...... they can't seem to reproduce my issue.

So, Anyone else with a pc, please download my last posted scene, do a <F10> sequence render (Takes about 5seconds!) and then look at frame 40... That red block should be in the middle of the screen! Which is the case when doing an <F9> from Layout..

This is what I get....
143404

Please let me know what YOU get. It might save you A LOT of time when you need to use this kind of setup.

Jarno
11-23-2018, 02:30 AM
In LightWave motion evaluation always comes before object replacement. So trying to make motion depend on the result of object replacement is not going to work as you want it to.

peebeearr
11-23-2018, 02:47 AM
In LightWave motion evaluation always comes before object replacement. So trying to make motion depend on the result of object replacement is not going to work as you want it to.

Hi Jarno,

I did not know that. Excuse my ignorance but why does the motion evaluation do its job when you 'give it time' by manually scrolling to, in this case, frame 40 in layout but not at render time? Would it be an idea to have an option (just like the present displacement/bones/morph/subdivision in Object Properties) to shift the order in which the evaluation would take place?

Is there a reason for having the motion evaluation happen before object replacement or is it a matter of choice? As far I can see it would make more sense to me to have it happen after object replacement as you, obviously, WANT the object replaced at a certain frame?

Jarno
11-23-2018, 05:11 AM
Layout tends to reevaluate the scene multiple times with the same frame time after scrubbing (for complex and not good reasons). So you are still seeing the effect of the motion using the previous evaluated frame, except that the previous frame happens to have been the same frame. Rendering does not do the frame evaluation duplication, so it tends to exposes evaluation order faults better.

Object replacement coming after motion evaluation is a choice that was made many, many, many years ago. It is based on the decision that mesh evaluation (deformation, subdivision) comes after motion evaluation, and object replacement being somewhat like a mesh operation.
Mesh evaluation was placed after motion probably because of bones.

Over the years there have been improvements made that allow some mesh evaluation to occur during motion evaluation, because people kept wanting to do things that didn't fit in LightWave's fixed linear step by step scene evaluation order (e.g. place an item on a deforming mesh). It is currently not possible to extend that to object replacement.

raw-m
11-23-2018, 06:42 AM
Layout tends to reevaluate the scene multiple times with the same frame time after scrubbing (for complex and not good reasons). So you are still seeing the effect of the motion using the previous evaluated frame, except that the previous frame happens to have been the same frame. Rendering does not do the frame evaluation duplication, so it tends to exposes evaluation order faults better.

Object replacement coming after motion evaluation is a choice that was made many, many, many years ago. It is based on the decision that mesh evaluation (deformation, subdivision) comes after motion evaluation, and object replacement being somewhat like a mesh operation.
Mesh evaluation was placed after motion probably because of bones.

Over the years there have been improvements made that allow some mesh evaluation to occur during motion evaluation, because people kept wanting to do things that didn't fit in LightWave's fixed linear step by step scene evaluation order (e.g. place an item on a deforming mesh). It is currently not possible to extend that to object replacement.

Thanks for posting. This would be why, when I use Motion Options on a null to track a point on a FFX object it always renders a frame behind. Baking seems the only way around it before rendering(?).

jwiede
11-23-2018, 11:52 AM
In LightWave motion evaluation always comes before object replacement. So trying to make motion depend on the result of object replacement is not going to work as you want it to.


Layout tends to reevaluate the scene multiple times with the same frame time after scrubbing (for complex and not good reasons). So you are still seeing the effect of the motion using the previous evaluated frame, except that the previous frame happens to have been the same frame. Rendering does not do the frame evaluation duplication, so it tends to exposes evaluation order faults better.

Object replacement coming after motion evaluation is a choice that was made many, many, many years ago. It is based on the decision that mesh evaluation (deformation, subdivision) comes after motion evaluation, and object replacement being somewhat like a mesh operation.
Mesh evaluation was placed after motion probably because of bones.

Over the years there have been improvements made that allow some mesh evaluation to occur during motion evaluation, because people kept wanting to do things that didn't fit in LightWave's fixed linear step by step scene evaluation order (e.g. place an item on a deforming mesh). It is currently not possible to extend that to object replacement.

This is all highly valuable information, can you please point to where it is covered in the LW docs? Or add it somewhere?

:devil: