Object rotations and textures

[Baddcog]

Darkman was having an issue where 2 pine trees were showing (wireframe 2) through his walls with a portalled window closed and he couldn't figure out why.

 

So I took a look. His portals worked correctly, and the model itself (2 trees actually) didn't clip into the room.

 

I did notice in the editor that they were rotated in the z axis. This is probably known, but when rotated the bounding box becomes quite large. It must take the points of the square the model is in (unrotated) and keeps them as the outside of the model, then when rotated 45* the bounding box grows to encompass those points so it is still square.

 

Odd behavior as the trees are round (they don't get larger as rotated, just the bounding box).

 

Probably an open source fix if possible but maybe something can be done? It happens with all models, mushrooms, etc... Of course small models probably won't cause an issue. And even in this case it was a small/well optimized room so even rendering the trees outside (or at least not culling them) wasn't causing performance issues.

 

And I don't know if there are really too many cases in which this would cause any major issues. You'd probably have to have 20-30 rotated models close to a wall to cause slowdowns. Might not even be worth looking into.

-------------

 

On another note,

 

I have got TDM up to date. Have DR 1.5.0 64.

Quite a few models having missing shaders (not sure if that was a 1.5 or 1.6 fix that I read about)

 

EDIT

seems the tex are back to normal and working in 1.6

[Tels]

Darkman was having an issue where 2 pine trees were showing (wireframe 2) through his walls with a portalled window closed and he couldn't figure out why.

 

So I took a look. His portals worked correctly, and the model itself (2 trees actually) didn't clip into the room.

 

I did notice in the editor that they were rotated in the z axis. This is probably known, but when rotated the bounding box becomes quite large. It must take the points of the square the model is in (unrotated) and keeps them as the outside of the model, then when rotated 45* the bounding box grows to encompass those points so it is still square.

 

Odd behavior as the trees are round (they don't get larger as rotated, just the bounding box).

 

Probably an open source fix if possible but maybe something can be done? It happens with all models, mushrooms, etc... Of course small models probably won't cause an issue. And even in this case it was a small/well optimized room so even rendering the trees outside (or at least not culling them) wasn't causing performance issues.

 

And I don't know if there are really too many cases in which this would cause any major issues. You'd probably have to have 20-30 rotated models close to a wall to cause slowdowns. Might not even be worth looking into.

 

This is a known issue with the AABB (axis-aligned boundary box). The code refers to "Rotate" when in fact it rotates the box, then creates the minimum sized box aligned with the axis that fits that rotated box, creating a much larger box than before, and you end up with an AABB again.

 

Technically, one would use a "idbox" (instead a "idbounds") object instead. However, id software in their goal to optimize down to the minimum needed instruction never really finished their "idbox" code (it mostly works, and I added a few nec. methods) and also never really used it.

 

So all the collision code uses a AABB for a quick check, and if that check says "it collied" then it looks further. In case of the "is in area X", the code simply uses the large AABB and determines "oh yes, this intersects the area".

 

I am not even sure this is fixable, because this is probably deep inside the renderer. Maybe there is a place in the open code that says "determine if this is in area x" and it is fixable.

 

A workaround *might* be to tell the tree to use a cylinder as bounding box - however, I am not sure if the renderer pays attention to this info, or if it always assumes a AABB anyway.

 

In any event, it should be documented on the wiki, because it is only know to programmers and not mappers.

[HMart]

On 4/16/2011 at 9:03 PM, Tels said:

 

This is a known issue with the AABB (axis-aligned boundary box). The code refers to "Rotate" when in fact it rotates the box, then creates the minimum sized box aligned with the axis that fits that rotated box, creating a much larger box than before, and you end up with an AABB again.

 

Technically, one would use a "idbox" (instead a "idbounds") object instead. However, id software in their goal to optimize down to the minimum needed instruction never really finished their "idbox" code (it mostly works, and I added a few nec. methods) and also never really used it.

 

So all the collision code uses a AABB for a quick check, and if that check says "it collied" then it looks further. In case of the "is in area X", the code simply uses the large AABB and determines "oh yes, this intersects the area".

 

I am not even sure this is fixable, because this is probably deep inside the renderer. Maybe there is a place in the open code that says "determine if this is in area x" and it is fixable.

 

A workaround *might* be to tell the tree to use a cylinder as bounding box - however, I am not sure if the renderer pays attention to this info, or if it always assumes a AABB anyway.

 

In any event, it should be documented on the wiki, because it is only know to programmers and not mappers.

Sorry for the necro but I've seen this strange bounding boxes on my modified fhdoom engine, has this been fixed for TDM? If so can someone direct me to the necessary files/code that needs to be fixed. 

Using a idBox did helped me visualize a good BBox on my debug code but i'm afraid it only masks the problem and even tho it looks fine, the underlying AABB is in reality broken and will cause problems later.