Possible applications

Join the team. This area is for people who want to participate in OpenMW's development in one way or another.
User avatar
greye
Posts: 47
Joined: 21 Jul 2012, 16:00

Re: Possible applications

Post by greye »

Thanks for the kind words.
Zini wrote: Basically you need to copy and delete the object in the world model (delete = set count to 0). Then you also need to adjust the physics and the rendering, if at least one of source and destination cells are active. In case both are active, I suggest to do the rendering/physics part as move instead of copy/delete.
Please, correct me: only npcs and creatures are allowed to cross cell-borders and there are no magic flying carpets around.
Moving is possible by changing/recreating Ptr data and moving child scene node to proper parents. As I can see, physics relies on the same data.

Sorry, but I'll have to be absent for two days.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Possible applications

Post by Zini »

Please, correct me: only npcs and creatures are allowed to cross cell-borders and there are no magic flying carpets around.
Incorrect. Any object can be moved across a cell border. Movement here means change of coordinates. It does not necessarily involve actual movement (think of teleporting). You need to check if a coordinate change results in a cell change and then make appropriate adjustments to world model, physics and rendering.
Moving is possible by changing/recreating Ptr data[/quote

You probably mean the right thing, but it is worded a bit unfortunate. You can not move objects across cell borders at all, technically speaking. What you are actually doing is creating a copy of the object in the destination cell and then flag the original object as deleted. Same effect as a move, but under the hood its completely different.
and moving child scene node to proper parents.
That is correct.
As I can see, physics relies on the same data.
I am not sure if I remember correctly. But I think the physics system stores a Ptr for each object. Because the object pointed to will be deleted, the pointer must be replaced with one that points to the newly created copy.
Sorry, but I'll have to be absent for two days.
That is no problem. Short downtimes are to be expected with a spare time project.
User avatar
greye
Posts: 47
Joined: 21 Jul 2012, 16:00

Re: Possible applications

Post by greye »

Zini wrote: I am not sure if I remember correctly. But I think the physics system stores a Ptr for each object. Because the object pointed to will be deleted, the pointer must be replaced with one that points to the newly created copy.
Well, actually physics uses scene node names as handlers.
Zini wrote: Incorrect.
Understood.
User avatar
greye
Posts: 47
Joined: 21 Jul 2012, 16:00

Re: Possible applications

Post by greye »

Zini wrote:Basically you need to copy and delete the object in the world model (delete = set count to 0). Then you also need to adjust the physics and the rendering, if at least one of source and destination cells are active. In case both are active, I suggest to do the rendering/physics part as move instead of copy/delete.
Well, conceptually it is done but I'm not sure how to test it properly.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Possible applications

Post by Zini »

There are still a few things to fix (see github). Testing has to wait until the respective scripting instructions are ready. Another task of gus that I was considering giving to you, but since he is back now, we will just wait until he finishes it. We can merge both branches into master when they both are ready. Actually, gus will probably need your branch for his task, so you don't need to bother with it anymore once the changes we are talked about are in.

What do you want to do afterwards? The player control task is important and I think you can handle it. There was another coder who started to work on it, but I haven't heard from him for a while and since this issue is kinda urgent, I have no problem with giving it to you. If you want it, maybe start at the beginning (I divided it up into subtasks). The other coder has started in the middle, so if he comes back in the next couple of days we won't have a problem with overlapping changes.
User avatar
greye
Posts: 47
Joined: 21 Jul 2012, 16:00

Re: Possible applications

Post by greye »

Zini wrote:The player control task is important and I think you can handle it. There was another coder who started to work on it, but I haven't heard from him for a while and since this issue is kinda urgent, I have no problem with giving it to you. If you want it, maybe start at the beginning (I divided it up into subtasks). The other coder has started in the middle, so if he comes back in the next couple of days we won't have a problem with overlapping changes.
Sure, I'll have a look onto it.
User avatar
gus
Posts: 390
Joined: 11 Aug 2011, 15:41

Re: Possible applications

Post by gus »

Just tested your code for crossing cell border, it crash. Don't know what's wrong. If you want to test it, use my branch object_movement_creation and the setPos script instruction ;)
Also, I've trouble doing this: http://forum.openmw.org/viewtopic.php?f=6&t=937 (the moveObjectToCell function), so I wouldn't mind a little help^^

But maybe we should start a dedicated thread in the development forum.
User avatar
greye
Posts: 47
Joined: 21 Jul 2012, 16:00

Re: Possible applications

Post by greye »

At first sight the problem in movement object to inactive cell and moving it again. Seems like I'm dereferencing some of destroyed data. Will look onto it deeper.

It is curious that console commands aren't allowed to move object from inactive cells because there are no handlers for them.
User avatar
gus
Posts: 390
Joined: 11 Aug 2011, 15:41

Re: Possible applications

Post by gus »

Moving an object from an active cell to an active cell doesn't work either. For this specific case, i looked deeper in the code, here is what i found out:
the problem occure when mRendering->moveObjectToCell is called.
In this function, the problem comes from this line:
parent->removeChild(child);

My guess is that the child sceneNode is detached from it's parent, but is never reattached again to another sceneNode, which cause problems.

Also, the code logic escape me : from what i understand, you create a copy of the object in the new cell, and then move it back to the currentCell... seems strange^^
User avatar
greye
Posts: 47
Joined: 21 Jul 2012, 16:00

Re: Possible applications

Post by greye »

gus wrote:Moving an object from an active cell to an active cell doesn't work either. For this specific case, i looked deeper in the code, here is what i found out:
the problem occure when mRendering->moveObjectToCell is called.
In this function, the problem comes from this line:
parent->removeChild(child);
This is very strange because I can move objects between active cells. Also, addChild() is called from Actors::, Objects::updateObjectCell().
gus wrote:Also, the code logic escape me : from what i understand, you create a copy of the object in the new cell, and then move it back to the currentCell... seems strange^^
Incorrect. RenderingManager::moveObjectToCell() 3d parameter is used as previous cell (I was surprised too).

Well, it crashes on npc movement too, you're right.
Post Reply