Jump to content
The Dark Mod Forums

Bug: DR just made a prism that is the entire map.


Recommended Posts

DR just made a prism that is the entire map. (That is 131 074 units long.)

I made it from a brush block that was 1x1x0.375 units big, and was using the smallest grid size. The prism was going to have three sides, because I was going to make it a small gauge needle. ...and then I just pressed the button to create the prism, and suddenly I get a huge line going through the entire map. I don't know what more information I can provide, and I don't want to mess around with it, so I'm just going to undo now and try to make the prism from a bigger brush. Hopefully that will help.

Edited by Nort
Link to comment
Share on other sites

What version are you using?

I just tried this with DR3.0B6, and I get the same behaviour. However, there's not a brush created, if you look in the console:

 

Warning: removed degenerate brush!
Warning: removing empty parent entity.

 

Don't use grid sizes that small, if you need something that small it should be made in a modelling program.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

1 hour ago, AluminumHaste said:

What version are you using?

I just tried this with DR3.0B6, and I get the same behaviour. However, there's not a brush created, if you look in the console:

 

Warning: removed degenerate brush!
Warning: removing empty parent entity.

 

Don't use grid sizes that small, if you need something that small it should be made in a modelling program.

I don't recognize that version format. I'm using Dark Radiant version 2.14.0. I didn't know Dark Radiant even had a console, so maybe the red line I got was something else entirely. Like I said, I didn't mess around with it, just hit undo, and created the needle from a larger brush, which I then scaled down and reshaped without any further problems.

Learning how to use a modeling program can take weeks, so I'd rather you just give users clear boundaries instead, like an error saying "Prism too small to be created.", or better yet, simply allow them to create the prism, since it's not theoretically impossible.

Link to comment
Share on other sites

3 hours ago, AluminumHaste said:

I'm using the DarkRadiant 3.0 Beta 6 version but I get the same behaviour.

The console is accessed via pressing the N key.

Don't use small grid sizes, causes all sorts of problems.

Oh, I see: "Console" is one of the tabs in the Entity Inspector. I am assuming that these (19 or so) red entries of "PICO_WARNING: LWO loader discarded a polygon because it has != 3 verts (2)" is related to the wedge I made. ...so at least there's some error handling in place, if you know where to look for it.

I am a perfectionist, though, so if you give me a smallest grid size, I'm going to use it constantly. Instead of mere ghost stories to scare children with, can you tell me some examples of what to watch out for, as I continue to test the limitations of this editor?

...because first of all, the prefab "/mechanical/switches/call_button.pfb" uses wedges that are only 0.25 units big. Granted, they are out of alignment (set to actually be "0.250192" units big), but this prefab is officially approved.

...and second of all, other than this one issue, I've actually had no problems using the smallest grid size.

(I tried to search the bug tracker for "grid size", but apparently its search engine can only take issue numbers.)

Link to comment
Share on other sites

There's a thing called vertex drift. Rounding errors. Causes sparklies in geometry in game (holes in the triangles as the vertexes no longer line up to grid, and you can see through them).

Using the smallest grid size to place models (LWO, ASE) should be fine. But brush geometry and patches should be aligned to grid, preferably at Grid 4 to avoid issues.

But by all means, if you're testing the limitations of the editor/engine, go for it. Hopefully, you'll learn before spending 100s of hours on making a map/mission, just to find that things don't work like they're supposed to.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

3 minutes ago, AluminumHaste said:

There's a thing called vertex drift. Rounding errors. Causes sparklies in geometry in game (holes in the triangles as the vertexes no longer line up to grid, and you can see through them).

Using the smallest grid size to place models (LWO, ASE) should be fine. But brush geometry and patches should be aligned to grid, preferably at Grid 4 to avoid issues.

But by all means, if you're testing the limitations of the editor/engine, go for it. Hopefully, you'll learn before spending 100s of hours on making a map/mission, just to find that things don't work like they're supposed to.

As large as a size of 4, even? Wouldn't it be better if you devs just increased the floating point precision instead? Moving a decimal point shouldn't be that hard, to achieve a much higher brushwork quality. I'd rather have "sparklies" than adhere to a grid size of 4, honestly. We're not mapping in Dromed anymore.

Link to comment
Share on other sites

I didn't encounter this bug yet, but I have serious doubts it's because of precision.  I've already proven Radiant can handle ridiculously small sizes.  Saved, loaded and exported (to OBJ).  I wouldn't try to compile something this small, but making a mapobject is the correct way to go.

radiant_micro.jpg

Link to comment
Share on other sites

6 hours ago, LDAsh said:

I've already proven Radiant can handle ridiculously small sizes.

Some prefabs use 1e-8 values. (Granted, those are useless, and likely a byproduct of things like patch beveling, but they're still there.)

8 hours ago, OrbWeaver said:

Perhaps you should learn how floating point actually works on computers before making pronouncements on how "you devs" should "move a decimal point".

Believe it or not, we are not all ignorant children manually performing calculations with two decimal places because we're too thick to have considered the advantages of using three.

You can start here: https://en.wikipedia.org/wiki/IEEE_754

Fine, I'll just read it off the table on that page:

If you use 16 bits, you get an exponent of −14.

If you use 32 bits, you get an exponent of -126.

If you use the -128 bit standard, you can have an exponent of −16382.

Yes, you might have to use more bits, but it's not like we're trying to split atoms here.

...but on the other hand, maybe decimal handling is handled by the compiler, and that would involve trying to reverse engineer ID's core code.

Is it possible that ID are the ones messing up? ...because this isn't just a matter of mathematics. When you are capable of storing e-8 values, you can translate those into stable 0.125 values when it comes to leaks and displaying textures. You prevent leaks by looking for nearby vertexes and round them together, for example.

...but fine, I guess I can use func_static entities for any details that start acting up.

 

8 hours ago, AluminumHaste said:

Orbs, don't bother, it's just another one of "those" people.

Yeah, I am. I'm sorry. I tried to make a 3D cube once, and I failed horribly. Once my lines started looking like staircases because they were poking into some piece of memory storing the angles for those lines, I just flipped the table and gave up. It would have been fun to make a quad engine, though, just for the hell of it - just to make Carmack cry. ...but beyond that, I don't know much about actually 3D rendering core programming.

 

Edit

The reason I'm saying "Just move the decimal point.", is because the coordinates only add up to 19 bits. If you add a few engine rounding calculations to that, you end up somewhere around 24 bits, which is far from a single double word. ...and so it doesn't seem like we're talking type conversions here, but even so, type conversions shouldn't be that hard to do either. ...but that all depends on if you're even allowed near the ID Tech engine, I guess. I just expected more out of ID, if that's the best they can do. They were cutting edge once.

Edited by Nort
Link to comment
Share on other sites

The Doom 3 engine is open source......

EDIT: Also, DarkRadiant's fork was good enough that it was used to build the maps for Titanfall. That's a pretty good endorsement.

 

So if they can make things like this with DarkRadiant:

TitanFall-9.jpg

 

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

18 minutes ago, AluminumHaste said:

The Doom 3 engine is open source......

EDIT: Also, DarkRadiant's fork was good enough that it was used to build maps for Titanfall. That's a pretty good endorsement.

Completely open source? Nice.

Look, if it's too much for you, I understand. You're not stupid or anything like that. On the contrary, I assumed you could do it because you were smart. ...but editing an engine is hard for most people - I get it.

 

"Also, DarkRadiant's fork was good enough that it was used to build maps for Titanfall. That's a pretty good endorsement."

Impressive, but multliplayer run-and-guns actually don't require any hi-def brushwork, 'cause the focus will be on the player model and other things. I guess things would be much simpler if I was simply a modeller - then I could just go nuts.

In any case, I can't find any information on what "vertex drift" is on the internet. It's possible that it's what I'm seeing in certain textures, where my wood pillars look like they're burning pink. (I'll turn them into func_static later.) I've not had any other issues with small sizes. In fact, often vertexes end up between the grid points, and require smaller grid sizes to not "drift" when I snap them to the grid.

I have half a mind to start sculpting spiral pillars made out of hundreds of 0.125 sized brush wedges, just to see if they turn out fine, because I want to see these issues, and know when they occur.

Edited by Nort
Link to comment
Share on other sites

Interesting:

If you group several 0.125 wedges together, they desynch from the grid (which is normal), but if you then take each of these individual wedges, they can only snap back to the grid at certain rotations. At one rotation, DR instead responds with

"snapSelected -grid 0.125000
translateTool
WARNING: invalid plane after snap to grid
WARNING: invalid plane after snap to grid
WARNING: invalid plane after snap to grid
WARNING: invalid plane after snap to grid
WARNING: invalid plane after snap to grid
snapSelected -grid 0.125000"

and the brush disappears.

This seems like something that can be fixed without requiring more precision, since it seems to snap just fine for wedges rotated in other 90 degree directions.

It may seem like a small detail, but if it's these tiny miscalcs that result in "vertex drift" at 1 unit grid sizes, then that's a bit of a concern, imo.

Link to comment
Share on other sites

3 minutes ago, LDAsh said:

Best practice is to CTRL+G when making primitives that are likely to not have vertices snapped to a the grid.

Well, not always. First of all, remember that it snaps to the current gridsize. Second of all, take care to align things so that components don't begin to misalign from eachother. Model doors is for example something that you should never snap to a grid, because their handles will desynch. It would be great if they were set up to snap to a grid, but they're just not. ...and third of all, my last post was about tiny brushes disappearing when snapped to the grid. Know when to snap things to the grid.

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

      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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...