Jump to content
The Dark Mod Forums

Object rotations and textures


Recommended Posts

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.

ROTATE.jpg

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

 

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

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

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.

ROTATE.jpg

 

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.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

  • 8 years later...
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. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...