This is a simple question; when exporting a parent collision solid that is a Polyset, with the value of “descend”, a collision is not triggered for all it’s children, but only for it. This is the process I use in blender to make it:
Select the to-be-child geometry.
Select the to-be-parent geometry last.
Press CTRL+P, then select object from the pop-up menu.
Click on the parent geometry.
Go to the logic editor, add the property: Collide, , Polyset descend
Go back to 3d view, select everything, export to .egg format.
I think that’s how one goes about it. I then took the code from the collision tutorial posted on the forum and just changed the name of the .egg file, and also, the collision tag. Running the script works, but as I said, only on the parent geometry; the collision data for the child geometry isn’t considered.
Interesting, with the simple file (attached) I see only one collision solid in pview, but all geometry is invisible and hierarchy list (shift+L) says that there are two collision solids.
Also if I remove “descend” flag, then all CS and visible geometry will fully removed, though as I understand manual - in this case it should be creating one CS and keep visible geometry of child group.
I can make emulation of descending in YABEE, but if it’s a bug, then better if it will be fixed untitled.egg (1.28 KB)
Thanks ninth, alright, if you are going to make an emulation, then I’ll wait; if it is a bug and will be fixed, then I’ll wait. The other way would be of course to just tag all collision solids to be exported, but can you imagine doing that for an entire city with over 300 buildings!
If there is a , no visible geometry under that group is kept unless there is also “keep” – no matter whether there is “descend” or not. I’m not sure if this is a particularly intuitive design, but it is the design of the system, so I see little reason to change that. In that respect, pview loads the visible geometry correctly.
What I expect to be seeing, though, is that when I set it to “Polyset”, I see a single plane, but instead I see zero. The behaviour of “descend” here is not what I expect. I’ll look further into this.
Oh, you’re right. With “descend” on the parent, I indeed see only one collision polygon, unless I also set “keep”. This is not the behaviour I expected. I’ll look into it.
This would appear to be the case, although I’m not entirely sure that this behaviour makes sense. I suppose it kind of makes the flag useless, eh - if the user really wanted this behaviour, why would he add the child groups at all? I’ll think about this.
Alright, not to be impolite, but when should this issue be fixed? And if it is fixed, what is the way forward? I ask because I finished doing all the environments, and for them, the last thing is just to add the collision geometry. Should I just tag everything or wait a while?
I was just about to post a reply saying that I had pushed a fix, when I noticed your post. Sorry it took me so long to get around to it.
The problem was that “descend” ignored transforms of child groups when descending. So, in ninth’s example, the two planes did both generate collision geometry, but they were overlapping. (I can only assume your problem is the same, since you didn’t post an .egg file). This should now be fixed.
The other issue that ninth reported, namely that no collision geometry is exported at all when “descend” is not specified, has to do with the Egg loader creating invisible “binning” groups for sets of polygons in certain occasions, and the loader doesn’t consider looking below them. This will be trickier to fix, but I’ll look into it.
The third issue that was brought up, namely that nested geometry is invisible when neither keep nor descend is specified, is something I’m still not sure about whether it is a bug or intended behaviour. I’ll consult with David on this.
Yes the same issue that was happening with his file was also happening with my file. Thank you for the fix at least now I can know what to do and at least other issues have been addressed or are being addressed as well.
ninth, after discussion with David it seems best to make “descend” the default behaviour, and discourage omitting it. What it does is take the polygons from a nested group element, and not (as one might expect) from polygons directly under the group. It was created to support a very old workflow that Disney used to use before they even thought of adding the “descend” feature, and the behaviour is certainly not intuitive or useful for anyone nowadays.
I’ll add a warning for 1.9 saying “Using without descend is deprecated. ‘descend’ will become the default in a future release.”
Sorry it took me so long to get around to it.