Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Bug Reports / Crash when deleting a cloned object w/shared data if it has animation

Author
Message
Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 31st Jul 2007 06:04 Edited at: 31st Jul 2007 06:05
Use attached media for testing. box_anim1.X contains animation and box_null.X does not.



http://3dfolio.com

Attachments

Login to view attachments
Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 15th Feb 2009 20:36
Can anyone think of a work-around for this? I should have remembered to bring it up during the 7.1 beta.

gamerboots
15
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 7th Feb 2010 06:07
you are deleting the primary object that object 2 depends on in your code.
but , if you try :

works like a charm.

----------------
Gamerboots~
Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 12th Feb 2010 21:47
Clone object is supposed to create a copy with no dependencies. Instancing is what relies on a source object.

gamerboots
15
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 13th Feb 2010 05:44 Edited at: 13th Feb 2010 09:18
normally this would be true, however, since you specified "1" in your code for the 3rd parameter it shares all animation data and therefore object 2 depends upon on 1 being in existance.
This causes the program to crash.
The work around for you is to omit the third parameter from your code so that it defaults to not sharing any data:


----------------
Gamerboots~
NeX the Fairly Fast Ferret
18
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 13th Feb 2010 12:33
There should be a handler for this, really. What's to stop it moving the animation data to the clone?

Athlon64 2.7gHz->OC 3.9gHz, 31C, MSi 9500GT->OC 1gHz core/2gHz memory, 48C, 4Gb DDR2 667, 500Gb Seagate + 80Gb Maxtor + 40Gb Maxtor = 620Gb, XP Home
Air cooled, total cost £160
gamerboots
15
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 13th Feb 2010 13:56
Hi nex, if I understood your question correctly my answer would be the same - (recap)
what stops the animation data from being moved to the clone is that the optional parameter in his code was set to "1" (shared animation data)
now once the primary object is deleted then when the object that depended on it tries to access the animation data it simply no longer exists, but the pointer to it does and the result is that it gives you a little bit more grinding before it notifies you that its crashed.
so this is not really a bug, it works exactly the way it was supposed to from what I can see :


Quote: "The only time a cloned object is dependent on the source is when then optional parameter to share animation data is used. You may wish to share animation data because it can easily consume megabytes of memory, and cloning many animated objects for your application might cause an unnecessary drain on system resources."


----------------
Gamerboots~
NeX the Fairly Fast Ferret
18
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 14th Feb 2010 19:23 Edited at: 14th Feb 2010 19:23
Quote: "Hi nex, if I understood your question correctly my answer would be the same - (recap)
what stops the animation data from being moved to the clone is that the optional parameter in his code was set to "1" (shared animation data)
now once the primary object is deleted then when the object that depended on it tries to access the animation data it simply no longer exists, but the pointer to it does and the result is that it gives you a little bit more grinding before it notifies you that its crashed.
so this is not really a bug, it works exactly the way it was supposed to from what I can see :"


I don't think you actually bothered to read my post at all. Why not just make one of the instances the new "master" when the master is deleted? No copying would be required beyond pointers to the animation data and a quick shuffle of the lists.

No crash, no overhead, just WORKING.

Athlon64 2.7gHz->OC 3.9gHz, 31C, MSi 9500GT->OC 1gHz core/2gHz memory, 48C, 4Gb DDR2 667, 500Gb Seagate + 80Gb Maxtor + 40Gb Maxtor = 620Gb, XP Home
Air cooled, total cost £160
Mistrel
Retired Moderator
18
Years of Service
User Offline
Joined: 9th Nov 2005
Location:
Posted: 15th Feb 2010 00:44 Edited at: 15th Feb 2010 00:46
I was under the impression that this flag was necessary otherwise no animation data was "shared" or "copied". I'd never actually tried playing the animation on a clone without this flag.

I just tested it and it's fine with the shared flag as 0. The animation is copied and it doesn't crash when animated.

There is no bug here at all.

Thanks for the heads up, gamer boots.

gamerboots
15
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 15th Feb 2010 01:10 Edited at: 15th Feb 2010 01:44
your welcome. I was glad to be of assistance

----------------
Gamerboots~
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Feb 2010 20:49
Actually, I agree with Nex that this is a bug.

Deleting the original data when multiple objects are sharing the resources (either via clone or instance) should either report an error, or move the data to another object and redirect all clones/instances to that object.

Under no circumstances should the program just crash out.

gamerboots
15
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 25th Feb 2010 03:10
hi Ian, I agree that it should report some kind of error when the user deletes the original data as it currently does not. Atleast something to let the user know that they have deleted shared data would be a lot better than a grinding halt.
Another question I am wondering about is whether or not that this was the way it was meant to originally be. I see no problem with an additional optional parameter except that suppose that you have thousands of objects depending on one object. would it not be faster to simply hide the original object rather than update the references of all the objects that depend on it?
What would the impact be on the speed at run time when doing this?

----------------
Gamerboots~
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 28th Feb 2010 14:05
Hiding instead of deleting? Well you have to go some way towards deleting because you have to make the object id available for reuse or else I'd get bug reports of people complaining that DELETE OBJECT isn't working.

You could disconnect the object data from the object id, but then you need to keep careful track of how many clones with shared data or instances exist for that object and ensure that the object is fully deleted when the last clone/instance is gone - get it wrong and you are either deleting too early, or you end up with a memory leak.

Also, depending on how it works internally, you may also need to continue to update the animation for the original object while it exists.

However, that is a valid third option and I'll make sure it's considered as a possible direction to go.

gamerboots
15
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 28th Feb 2010 18:12
I was thinking that it would be easier for the coder to simply hide the object for later use rather than delete them. sorry for not being more speciffic on that.
To be honest though, I think the coder should use some kind of discretion when creating or deleting objects with shared data to avoid this situation to begin with. It only takes a few seconds to write down object dependencies (assuming they can type fast).

----------------
Gamerboots~

Login to post a reply

Server time is: 2024-03-29 06:21:35
Your offset time is: 2024-03-29 06:21:35