Jump to content
The Dark Mod Forums
Sign in to follow this  
grayman

DR and its shifting planes

Recommended Posts

Does anybody have a example for the shifting planes issue including reproducible steps?

Easy peasy:

 

Make a new map. Create 8x8x8 cube.

In Y/X view, cut the cube diagonally with the clipper.

Deselect cube.

Select a single piece of the cut cube.

In Z/X view, cut the piece diagonally with the clipper.

 

Select the whole bunch.

 

Move the whole bunch around. First the piece is 8x8x8. When you move it in grid 8 and release the mouse button, it looks like it is 8.00004. The more you move, the higher the error becomes: after a few moves it is already 8.00013.

 

This happens in DarkRadiant 2.0.2pre5 x64


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

Ok, thanks. I got this one fixed, I think.

 

In pre5, I can see that the dimensions change when moving the cube on grid 8: I drag it 800 units on the x axis and the dimensions change to 8.00004 or something, when dragging the cut cube back to the origin the error becomes higher. Repeat these steps and the error piles up.

 

In my working copy, I can drag the cube to x+800, the dimensions change to 8.00002, when dragging it back the dimensions become 8 again. I can drag them as often around as I like, when moving them back to the origin the dimensions seem to be at flush 8.

 

These changes are in my post-2.0.2 branch, so I can put up a new pre-release build with these changes when 2.0.2 is out.

 

Are there more problem cases to look at?

Share this post


Link to post
Share on other sites

Nice...but shouldn't it be so that the object dimensions always stay the same no matter where you move it? That is, moving an object should not affect the dimensions of the object at all.

 

It is not helpful, if the dimensions remain the same only if you move it back into the original position.

 

A common way to get mapping problems because of this bug is to cut a slanted brush and make rooftops with it by cloning. You always move the slanted brush to a new place. Now they get corrupted and if the joint is caulked, it produces ugly artifacts when the void is visible between the corrupted joints.


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

I'm not entirely sure, but I think it's unavoidable that some precision is lost when moving away from the origin. A floating point number as used in computers can only store a certain number of significant digits. When the number is already up in the thousands, most of the significant digits are used up by the number left to the comma, and less precision is left to the post-comma digits.

 

Also, the size info displayed in DarkRadiant is based on the bounding box of the object - so while it might seem that the object is falling apart (when displaying a width of 8.0011), the actual vertices of the cut up cube might still be perfectly aligned to each other (which is the important thing to avoid leaks or have textures shining through). So even if the size info indicates there's something amiss the object might stil be intact.

 

The only way to keep precision within the map would be to use a different internal format for the brushes or to use transformation stacks (local coords for the cube and a transform matrix for the translation to its final position in the map). This would only happen during the mapping phase though - the final compiled map will still have to calculate the final vertex positions and vectors, which is where the foating point precision issue will kick again, and when sending the data to the graphics driver (at the latest) one might get some of the effects back.

 

I'm open to new examples of things getting corrupted. Give me a uncorrupted prefab and tell me steps how to corrupt it, then I can do some research about how it became foul. It should be leading to actual visual problems (not only size info showing weird post-comma digits, but actual textures shining through or vertex joins getting out of touch).

 

I'm not arguing that these things don't happen and that you're imagining things, I'm only asking for reproducible stuff, that's what I need to investigate it.

Share this post


Link to post
Share on other sites

I think I know exactly the type of geometry that is problematic and will show texture issues.

 

I'll be busy for the next couple of days, but will try to provide one at my next opportunity.

 

If you need something really quick, I suppose openining the Phrase Book .pk4 map and examining the slanted rooftops in the large outdoors area with the balconies (start in the tower, get up, go through the small inn, and now you are in the area.)

 

IIRC these slanted roof brushes were extremely prone to corruption, and I saw caulk seeping from the joints after I had moved them into place. In the end, I think just applied the roof texture on the entire brush just to make the corruption less visible. I didn't have the energy to start fixing them, and I felt they just kept appearing.

 

But that was an older version of DR, so it might be better now. I'll test later.


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

Yes, no need to hurry, I'll be waiting for a proper test case if you can find the time.

Share this post


Link to post
Share on other sites

Seems like if everything is snapped to grid when mapping, then the verticies should be only whole numbers with one of 4 - 3 digit suffixes. Isn't there a way when doing the calculation to just use a significant digit figure of 3. So all of our smallest grid snapping numbers are covered. 1.000, .500, .250, .125. Then add a conditional check or case that says if a number is close between one of these values, round to the nearest grid point: .000, .500, .250, .125?

 

As a side effect, verticies that were not properly snapped to a grid size might get rounded the wrong way exposing pink caulk and pointing out that the geometery was not properly snapped to grid.

 

I'm sure since this seems so simple and trivial there is something preventing this from occuring but I thought I'd chime in with my ignorance :) I know you guys are sharp but still sometimes the simple solutions evade us.

Share this post


Link to post
Share on other sites

Having everything snapped to the grid is not always possible. While sealing geometry definitely should be snapped to a fairly large grid, many smaller objects built from brushes and patches are freely rotated and cut and CSG'd or whatever. DR can't decide for you whether these objects should always be grid-snapped or not. On top of that, grid-snapping for brushes is vertex-based which can lead to weird distortions when the snapping code is forced to attempt to fit a plane into more than 3 vertices - it's very easy for smaller brushes to end up non-convex during this phase, which means that they will be invalid and most likely have its faces removed.

Share this post


Link to post
Share on other sites

I once posted a python script that would select any non-gridsnapped brushes to help mappers find glitches. It turned out to be a complete red herring. First, there're are plenty of worldspawn brushes that you don't want gridsnapped (think carved clip brushes, ladders, nodrawsolid_water etc) so every map gave 1000s of false positives, and second, alignment glitches like VPs interfering are often not related to stuff being off-grid in the first place. A slightly different problem to the one of translating brushes and having them stay aligned, I'm just sympathizing that the one time I tried to help in this area I quickly ran into a brick wall.

  • Like 1

Share this post


Link to post
Share on other sites

I was thinking about the way brushes are represented and how that data would be expected to change given different transformations. The surface normal of a plane would remain constant during a scale or move operation. It's the distance component of the plane equation where the precision issues arise. Then when you account for rotation the entire plane grouping is subject to precision issues. What strikes me as odd about the data structure is the emphasis put on preserving the orientation of faces when what we really care about are the intersection points. Why did id opt to store the brushes this way? Is it simply to save disk space?

 

I'm curious if the older brush structures from Quake, Q2, Q3 suffered the same problems. This issue may persist until we change the map format and that could be a huge undertaking.

  • Like 1

Share this post


Link to post
Share on other sites

Some so called 'open world' engines

move the entire

world as a unit ingame

instead of moving the pc because of 'from origin precision problems'. That is the geometry never becomes crazy because it's always 'near the origin'

 

Crazy right? Doesn't sound so relevant to the DR error though. I think.

Edited by i30817

Share this post


Link to post
Share on other sites

greebo, I would've liked your post too but apparently you're not likable.... I disagree but...there it is, you're unlikeable. :P

 

Thanks for the answers.

Share this post


Link to post
Share on other sites

I'm curious if the older brush structures from Quake, Q2, Q3 suffered the same problems. This issue may persist until we change the map format and that could be a huge undertaking.

 

Quake 3 maps had the same issues.

 

To avoid these issues entirely, floats can't be used. Anything that would require fractions for vertex coordinates, should be made as mesh model in a 3D App. It's a bit limiting, but sounds like the only easy solution :(

 

Also, precision loss shouldn't even occur within +/- 32k distance. Why would 8.000000 become something else if moving it 1000 units along any axis ?!

Edited by motorsep

Share this post


Link to post
Share on other sites

Yes, no need to hurry, I'll be waiting for a proper test case if you can find the time.

 

I took a portion of the geometry I know was corrupting in Phrase Book.

 

In DarkRadiant 2.0.2pre5 x64, the offending geometry DID get a digit change from 80 into the strange 79.9994 regime when I moved it around.

 

However, if I carefully observe the geometry piece in 3d camera view and snap it into grid, the value shifts from 79.9994 into 80. In the camera view, I see absolutely no change.

 

This indicates that the decimal shift has no effect on the actual appearance.

 

Unless someone else presents a visually broken geometry, I suppose all is well!


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

I was thinking about the way brushes are represented and how that data would be expected to change given different transformations. The surface normal of a plane would remain constant during a scale or move operation. It's the distance component of the plane equation where the precision issues arise. Then when you account for rotation the entire plane grouping is subject to precision issues. What strikes me as odd about the data structure is the emphasis put on preserving the orientation of faces when what we really care about are the intersection points. Why did id opt to store the brushes this way? Is it simply to save disk space?

 

I'm curious if the older brush structures from Quake, Q2, Q3 suffered the same problems. This issue may persist until we change the map format and that could be a huge undertaking.

I can (naively!) imagine writing a converter between plane-normal format and vertex-coordinate format in an afternoon and plugging it into DR and dmap over the course of a few days. I don't think it's the effort of a different map format that stops it happening. I suspect the real issue is WYSIWYG. The engine mechanics rely heavily on BSP trees, and BSP trees are built from planes. If DR worked in vertex coords and dmap converted those to planes internally, you'd get leaks and misalignments that you could do absolutely nothing about.

Share this post


Link to post
Share on other sites

Representing polytopes via their adjacenting plane is very common in mathamatics, especially in numerics and optimization. It has a couple of benefits, for example if you want to find out whether something is inside such a volume. With vertices, this is much more difficult. In addition, the engine relies on convex surfaces (for triangulation, I guess). Creating non-convex surfaces is not possible with this setup.

 

The earlier mistake found was that during a translation a rotation was applied, too, and that it was put in an unneeded way creating rounding errors. (see here: http://forums.thedarkmod.com/topic/14375-dr-and-its-shifting-planes/?p=302075)

 

However, it may still occour that rotation is taken into account, even if none happens (translation only), which can produce rounding errors. And there was an issue with the normalization of the plane normals (which are already normalized, hence their name). Don't know if this is still present, though.


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

Representing polytopes via their adjacenting plane is very common in mathamatics, especially in numerics and optimization. It has a couple of benefits, for example if you want to find out whether something is inside such a volume. With vertices, this is much more difficult. In addition, the engine relies on convex surfaces (for triangulation, I guess). Creating non-convex surfaces is not possible with this setup.

 

The earlier mistake found was that during a translation a rotation was applied, too, and that it was put in an unneeded way creating rounding errors. (see here: http://forums.thedarkmod.com/topic/14375-dr-and-its-shifting-planes/?p=302075)

 

However, it may still occour that rotation is taken into account, even if none happens (translation only), which can produce rounding errors. And there was an issue with the normalization of the plane normals (which are already normalized, hence their name). Don't know if this is still present, though.

Man I really need to finish that Mathematics for 3D game programming book so I can take a look at this kind of stuff.

Edited by 161803398874989

You can call me Phi, Numbers, Digits, Ratio, 16, 1618, or whatever really, as long as it's not Phil.

Share this post


Link to post
Share on other sites

The book by Eric Lengyel is a very good read, I can definitely recommend that if you're referring to this.

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...