PDA

View Full Version : Is Lightwave STILL loosing its reference objects in surfacing?!?


dmack
01-09-2008, 03:10 AM
Hi All,

Anyone else STILL getting it where Lightwave removes reference objects in the surfacing panels. For example I have a gradient with an input paramter set to Y Dist to Object. I choose the object, do some tests, all fine, save the scene, network render it overnight and get bad results, go in and check the scene and the reference object that I chose has been replaced by (none). This has happened to me for soooo long but I assumed in the 9,.3 overhaul it would have been long ago squashed! Is this bug really still present?!?!!?!?

SplineGod
01-09-2008, 03:40 AM
Im having a similar problem with objects assigned to use bones from losing their assignments. It appears to be the old Object ID problems which I thought was fixed.

dmack
01-09-2008, 05:38 AM
Hmmmmm. That's dissappointing.

SplineGod
01-09-2008, 05:40 AM
Yup, Its bitten me several times on a project Ive been working on and making it not fun to work with.

StereoMike
01-09-2008, 05:59 AM
I encountered that aswell in former versions, didn't checked it recently, but obviously it's still there...
That's a real showstopper, cause you can't use screamernet...

mike

Phil
01-09-2008, 05:59 AM
Reported with content to lw-bugs@newtek.com? :)

dmack
01-09-2008, 06:05 AM
SteroMike - As I found out after the render farms ouput from the whole of last night is thrown into the bin.....and as you say, it stops you using screamernet. This type of thing simply shouldn't be happening at version 9.3.1. Dissappointed, really dissappointed.

Captain Obvious
01-09-2008, 06:21 AM
It's even more of a pain when the item info nodes lose their connections, because then you have to go through every single item info node in every single surface and fix it. Grrr.

Stooch
01-12-2008, 12:14 AM
oh my god thats retarded. i wont be buying an upgrade if that bug is still there.

Castius
01-12-2008, 12:34 AM
Thank you Stooch for your very clear and useless contribution to this thread.

That sucks that object references lost in multiple areas of layout. This used to be related to load order in layout. But with the new Object ID that seems unlikely. What would probable help to find the problem would be to do a difference test on saved versions of the scene file. That way you might be able to see over time what changes to these references.

evenflcw
01-12-2008, 12:45 AM
Well... looking at how the new IDs are stored, the old system is still not completely busted and exchanged. It could be that some features haven't been brought over to use the new system, and as such won't work right for the same reasons as before or other new but similar reasons (such as issues brought on by names being interpretted as name+id). The old LW scene format in this respect was pretty naive. I would feel more confident with a more strict file format, using tags or somesuch.

Stooch
01-12-2008, 01:10 PM
Thank you Stooch for your very clear and useless contribution to this thread.

you are welcome. I would appreciate if you kept your useless opinion to yourself though.
the "use" of me posting what i did is to let newtek know that for some people its a deal breaker. so fix it.

you can read more of my "useless" contributions in the open beta forum. where i go into great length about large scene management.
this is especially prevalent in large scenes and causes big problems. So again. STFU. I didnt comment on you until you commented on me.

Andyjaggy
01-12-2008, 06:22 PM
I'm surprised this didn't get fixed in 9.3.1. they squished a lot of bugs, apparently not this one.

dmack
01-13-2008, 06:35 AM
I'm surprised this didn't get fixed in 9.3.1. they squished a lot of bugs, apparently not this one.

Yes, got to to say that I was surprised as well. It's been such a long term problem that I'd have thought it was high on the priority list and smoething that really needed to be checked carefully before the release of 9.3.1. It's such a necessary feature that it's a bit crippling to have it missed off. Has there been any news from Newtek on this does anyone know?

Stooch
01-13-2008, 08:36 AM
the existence of this bug tells me that they are half assing it.

its a real shame.

Chuck
01-13-2008, 04:42 PM
Folks, there has not been such a volume of reports on these kinds of issues submitted to Fogbugz that would indicate a widespread problem, and we have in fact been keeping an eye peeled for them as we do want to address any such issues as quickly as they can be identified. If you have content that reliably shows the problem, please submit a bug report. If you have any examples of scenes where the connections were intact, and subsequent saved versions where connections of any kind were lost or broken, please submit reports and include these "before" and "after" scenes. From the comments on the thread here it sounds like this is happening with some frequency, so by all means report any such incident and provide any content that shows the problem. We'll get on it promptly.

Stooch
01-13-2008, 06:52 PM
OK, for the record this issue exists in hypervoxels as well. it actually surfaces in the HV surface manager the most for me because often I have ALOT of emitters - and it seems like the more items you have the more likely it will happen. this is NOT reproducible AFAIK. It happens randomly when you have alot of surfaces with a distance based gradient.

This issue also happens with lights as well.

for example sometimes i lose my light association with hypervoxels. it happens randomly on scene load.

You probably dont see alot of these reports because for most people only a few items are affected and they arent really bothered taht much. however for me i might have 30-40 affected surfaces at a time and since you guys said that you fixed the ID i assumed that it was fixed.

also antoher thing, sometimes when changing emitter attributes, the information in the emitter doesnt get updated until i change a value. so for example i select emitter 1 do some changes and then select emitter 2 and the settings look the same. UTIL i try to change a setting, where the value reverts to the actual one on hitting enter. i have to re-enter the value to actually make it stick.
all of these i believe are related to the object id issue.

By the way, this also happens with motion modifiers, again same deal, for me it usually happens to emitters that are referencing a light intensity for example. Sometimes i would load my scene to find taht my motion modifiers arent pointing to anything. Often if you delete the offending item and create a new one, the problem goes away.

by the way, speaking of emitters, if i delete my emitter cache, it for some reasons sets a new maximum particle setting based on the number of currently emitted particles on the last frame of the timeline. this is a huge pain in the *** as well.

Stooch
01-13-2008, 07:03 PM
just to point another thing, i usually work on about 2-4 shots a day, so i do ALOT of loading and load from scene. usually these happen on scene load so this could be another reason why not many people see it. So you guys should really look at your loading code, including load from scene and make sure that it preserves as much info as possible. especially paying attention to motion modifiers and emitter attributes.

i find taht emitter attributes are also a bit buggy, for example you cant load or properly save an emitters settings withouth clearing its particle cache. and clearing particle cache should not affect the max particle setting, it should revert to whatever setting it was when creating the cache int he first place. IE if i set it to 5000 but it only emitted 2000 when i baked to PFX, it should revert to 5000 if i later decide to delete the particle cache. Currently it will revert to 2000 and often require all 30 of my particle emitter settings to be reset. especially if i extend the frame range or increase the emission rate, causing an insufficient amount of particles at the end of my frame range.

Stooch
01-13-2008, 07:13 PM
Oh and another thing about emitters. often i have to scrub to the last frame of my timeline before baking to PFX, if i dont, it will only create PFX cache until the position of the playhead, after the playhead it will stop to generate particles and set a new max particle value for all emitters using the playhead location as the end of emission. This is a huge pain in the asss again, since it requires going back through all my emitters and re-set their max particle count.

oh yes almost forgot sometimes for no good reason, when using the save all command on my emitters, i get a red error dialog saying taht i cant save PFX file, i have to close and restart lightwave and re-set the PFX directory and then perform a save all in order to create the PFX files.

Also, why doenst the default PFX folder location - save upon scene exit? It saves the last opened LWS file so why not automatically remember the last PFX content folder or better yet, use the location of LWS path to atuomatically figure it out. with a project taht has a complex shot directory structure - LW requires a bunch of redundant clicking EVERYTIME i have to reopen a scene and export to PFX files.

I am aware that you guys improved the PFX functionality in the latest build, so im hoping that these issues im mentioning are somewhat squashed, i have no time for beta testing at the time to check for myself. and we arent running beta software at the studio.

Stooch
01-13-2008, 07:28 PM
oh yes another thing, i see this problem often with gradient driven emission rate in particle emitters. for example sometimes i want my particles to start emitting after a certain distance to a certain object. I would set my target to the emitter and duplicate the emitter say, 20 times.

sometimes i will find that on loading scene with no particle cache, i can see that all my emitters lost their distance to item goals and are starting their emission improperly (again gradient surface).

so it seems to happen across the board with all instances of the distance gradient.

sorry for the ****** grammar, i tried to fix but usually run out of edit time.

Stooch
01-13-2008, 08:20 PM
p.s. sorry for all the posts. since im not running beta, if anyone who is doing similar actions in 9.3 and can confirm any of these bugs it would probably help newtek. :) just keep it in beta forums, none of the items i listed are from the beta, im hoping that some are already taken care of.

Captain Obvious
01-14-2008, 04:23 AM
"Load from scene" will kill the connection of any item info node.

Chuck
01-14-2008, 12:51 PM
Thanks for the added observations! Please note that Fogbugz is not just for reports on the beta software - it is for any and all reports of bugs in any NewTek product. If you haven't noticed there are now instructions for use of Fogbugz at the top of every LightWave Support Forum section. Any problem you encounter, please report it via Fogbugz.

SaturnX
01-14-2008, 01:05 PM
Actually... im gonna chip in here while we're sort of talking HVs... :D
Ive been working on HV heavy scenes lately...
And going through the likes of 300+ HV settings one by one, (to make similar changes, IE: lights) can be both painful and tedious.
A multi select on HVs, to change similar options all at once would be much appreciated.
Or a spreadsheet equivalent, or BOTH!

:)

sat

dmack
01-14-2008, 01:25 PM
I've got to be honest and say that I find the 'put it on fogbugz' a little frustrating. It's a bug that's been around for a LONG time, has no doubt been entered onto numerous bug lists and can be rapidly reproduced on any semi-serious project. I, nor anybody else should have to spend any more time on this bug - it clearly hasn't worked in the past(!). Chuck, you've seen the issue, can you take over responsibility of this serious and on going bug and get someone to sort it out. Thank you.

4dartist
01-14-2008, 01:25 PM
I'd like to just say we are experiencing this as well. About 90% of the time, when i 'load from scene' another copy of my character or if I duplicate hierarchy, my 'use bones from' setting gets lost, on ALL objects using the 'use bones from' feature. I also have hypervoxels ramps loose their reference objects a lot. I always have to check it before renders because all too often do i render something and realize it lost the object thats why the render is all botched. Hypervoxel losing reference objects is far less common though. Maybe 5% of the time.

Stooch
01-14-2008, 02:42 PM
Actually... im gonna chip in here while we're sort of talking HVs... :D
Ive been working on HV heavy scenes lately...
And going through the likes of 300+ HV settings one by one, (to make similar changes, IE: lights) can be both painful and tedious.
A multi select on HVs, to change similar options all at once would be much appreciated.
Or a spreadsheet equivalent, or BOTH!

:)

sat

check out my feature request in the open beta forum :)

i basically went over the exact same thing,.

Cageman
01-14-2008, 04:28 PM
Ok... so THAT is why things just stop working when reloading a scene that, when saved, worked perfectly. I thought this bug was "limited" to 'Load From Scene'? I could live with 'Load From Scene' being wonky on some things, but a saved scene being messed up in places on a reload is... not a good thing!

Andyjaggy
01-14-2008, 04:45 PM
Well having load from scene broken is pretty pathetic too. It seems everyone else has a decent referencing system except for us :(

Captain Obvious
01-14-2008, 07:38 PM
If it's any consolation, modo's referencing system is actually mostly worse.

SplineGod
01-14-2008, 11:26 PM
Which makes sense since both came from the same source :)