backwards triangle in input! spam

[Xarg]

Trying to dmap, this comes up. I've had it once before but don't remember what I did to fix it. Anyone know how these are formed, and how to find and fix them? Very confusing error.

[nbohr1more]

I thought that was a benign error and just a normal part of the optimizer's task.

[AluminumHaste]

I thought that was a benign error and just a normal part of the optimizer's task.

 

It's a warning and can be ignored. That said, there's a reason for these, and I'm not 100% sure, but I think they are caused by using lots of small grid brushes, and/or small angles. Try turning some things into function_statics and dmapping again.

[ungoliant]

from what I've learned, these warnings can be ignored for the most part. That is, unless the triangles being optimized out are supposed to be in plain sight of the player. That can cause problems. If that happens just start fiddling with with the geometry around the area, or convert things to func_static. But actually getting an FM to release point without having a crap ton of backwards tris is an unlikely prospect. So ignore for the most part, but keep an eye out for missing pieces of things in-game

Edited November 29, 2010 by ungoliant

[Xarg]

I know there are a few of those warnings that come up during a dmap, but what was occuring was it'd go through those, get to degenerate triangles, then endlessly throw that error until it stopped responding. I found it was related to some octagonal brushes I had made, removing them has got rid of the dmap breaking spam. I'll try putting them back in, and creating a func_static out of them. Thanks for the idea!

[ungoliant]

I've had pretty good luck with stuff like octagonal brushes if you use the create brush prism function. If the brush you make it out of is too small, DR will usually just reduce the number of sides, telling you "that thing is too small to put that many sides on a prism". Still, it doesn't usually hurt to try snapping all the verts on one of those to grid just to make sure.

[AluminumHaste]

I know there are a few of those warnings that come up during a dmap, but what was occuring was it'd go through those, get to degenerate triangles, then endlessly throw that error until it stopped responding. I found it was related to some octagonal brushes I had made, removing them has got rid of the dmap breaking spam. I'll try putting them back in, and creating a func_static out of them. Thanks for the idea!

 

My doom3.exe also stops responding while dmapping at certain parts, you should wait to see if it ever comes back. Of course, just fixing the issue is the correct procedure, but don't worry if Doom3.exe stops responding, it's just busy.

[Xarg]

My doom3.exe also stops responding while dmapping at certain parts, you should wait to see if it ever comes back. Of course, just fixing the issue is the correct procedure, but don't worry if Doom3.exe stops responding, it's just busy.

 

If I can sit there watching it while I roll a cigarette, go outside and proceed to smoke said cigarette, then come back and it is still going... that's a little too busy for me . I'll try the brush prism and func static ideas, take it slow, see how it impacts as I add more of the object. Failing that, I'll just find an alternative to use.

[stumpy]

degenerate triangles do not get put into the proc file and you end up with triangle holes in brushes in game. its something along the lines of processing a triangle and its normal in the center of the triangle, if the normal points the wrong way then the triangle draws counter/anti clockwise, or clockwise depending how dmap sees workable triangles, then dmap bungs up an error saying it cant process those triangles cos the codes not there to do it.

[ungoliant]

Is it possible to run dmap without optimization? theoretically you could caulk every square inch of every unseen surface, which should theoretically render optimization worthless since caulk doesn't get drawn. Could save a lot of hassle on dmap time, and prevent weird aggravating map holes. if it its true that the .proc file is reduced by optimizations, that might also lead to larger FM's by leaving those surfaces in though. Anyone ever tried this?

[AluminumHaste]

Is it possible to run dmap without optimization? theoretically you could caulk every square inch of every unseen surface, which should theoretically render optimization worthless since caulk doesn't get drawn. Could save a lot of hassle on dmap time, and prevent weird aggravating map holes. if it its true that the .proc file is reduced by optimizations, that might also lead to larger FM's by leaving those surfaces in though. Anyone ever tried this?

 

No the optimizer does way more work than just caulk out unseen faces, it optimizes geometry and triangle output, and a bunch of other things. If it wasn't needed I'm sure ID would have just told us to make sure to caulk everything and would not have built an optimizer.

I build exclusively in Caulk texture anyways, and only texture faces I need to. This helps, but on some maps it doesn't matter how much you pre-optimize the DMAP process can still take 10 minutes like it used to for my Cathedral map. That is until I changed most things into func_statics.

[someTaff]

converting small brushes is func_static really helps!

[Serpentine]

If you're hitting this problem, where it eventually runs out of memory and hangs - please send me a copy of the map - or a simplified test case!

 

There are a few bugs in the dmap/optimizer which have alternative functions (which are disabled because they also have issues), but if I can get some test cases and narrow down where the bug lies and if one of the alternative solutions works, I'm sure it'll help make better maps and less annoying bugs are always good

[Tels]

There is also the problem that if you convert someting into a func_static, then triangles on the same func-static will cause other triangles that it crosses to split up.

 

E.g. imagine you have a grate where the horizonal beams are bigger then the vertical beams. Each vertical beam crossing the horizontal bar will cause the triangel on the hor bar to be split up into a smaller (very long and thin) triangle.

 

This means you and up with a ton of very small, very thintriangles just to draw small thin bar.

 

There are two ways to fix this:

 

* split the func_static into two parts one for the horizontal bars, one for the vertical bars

* the better way: turn the grate into an ASE object via the "Export ASE" script function and then just insert the object (multiple times save even more)

 

In one map I had inserting 3 or 4 grates as objects vs. func_statics dropped the dmap time from 32 to 24 seconds on my computer alone.

 

So beware of excessively turning everything into a func_static just because you can _)