Jump to content
The Dark Mod Forums

No leaks, but can see the void


grayman

Recommended Posts

Working on my first map.

 

Maybe this is discussed somewhere, but after searching the Forums, I found nothing.

 

My map builds fine (no leaks), but there's one wall brush that has a black "window" into the void. I can see through it, and see the interiors of other rooms w/in the view. The window is NOT the entire brush, just a section of it.

 

I've tried removing a nearby visportal. I've tried removing a nearby torch. I've tried replacing the "bad" brush and even changing the geometry a bit.

 

But the window remains. Has anyone encountered this? If so, how do I fix it short of redesigning the entire neighborhood?

 

I've attached two screenshots. The first shows the window in the wall. The second shows what I can see through the window.

 

post-3633-126619672815_thumb.jpg

post-3633-126619674198_thumb.jpg

 

Thanks!

Link to comment
Share on other sites

Working on my first map.

 

Maybe this is discussed somewhere, but after searching the Forums, I found nothing.

 

My map builds fine (no leaks), but there's one wall brush that has a black "window" into the void. I can see through it, and see the interiors of other rooms w/in the view. The window is NOT the entire brush, just a section of it.

 

I've tried removing a nearby visportal. I've tried removing a nearby torch. I've tried replacing the "bad" brush and even changing the geometry a bit.

 

But the window remains. Has anyone encountered this? If so, how do I fix it short of redesigning the entire neighborhood?

 

I've attached two screenshots. The first shows the window in the wall. The second shows what I can see through the window.

 

post-3633-126619672815_thumb.jpg

post-3633-126619674198_thumb.jpg

 

Thanks!

 

 

Looks like the Caulk texture has been applied. This won't cause leaks but you will see into the "void", the player should never see Caulk.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

This happens if you are using a very low grid size - it confuses the map compiler into optimizing out surfaces which should remain. Leaving these in a map results in a lot of performance being lost, so always good to find and fix :)

 

As said, try snapping the edges/vertices to grid. (And use a grid size like 1 - you get used to it, just remember the number keys can swap between sizes and it will become second nature to use higher sizes)

 

(And a tip : If you ever _have_ to use something very fiddly and get the issue, you can convert it to a func static (assuming it isnt sealing))

Edited by Serpentine
Link to comment
Share on other sites

To be more precise, this happens when there's a thin sliver left on a brush, usually at some weird intersection, and the sliver is usually right around where the portal-looking part starts. You can even have stuff overlapping or off-grid if you have to (though not recommended; like they say it's good to keep things snapped, flush, and on a larger grid size), but it's leaving a little sliver that gets you into trouble.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Thanks for the tips. I'm using a grid size of 8, so it's not a small grid size that's doing it.

 

And I don't use caulk.

 

There is, however, a slanted ceiling touching this brush, so perhaps the brush intersections at the top of the doorway (see pics) need some tweaking.

Link to comment
Share on other sites

And I don't use caulk.

 

You should, anything that the player won't see, should be caulked. Imagine the backs of buildings that players will never see, they should have caulk applied to their faces. I mean any surface that sees the void is optimized out by the compiler, but anything within the map will be processed during game play (except in some circumstances)

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

the other thing I was going to mention which your thing brings up ... even if you have a good big grid size, I've noticed you can still get in trouble leaving slivers when you have brushes intersecting at angles, because the grid just aligns the verticies on the nodes, but intersections can still be messy and not flush on the grid. If you zoom in very close you'll notice it. Sometimes you can move brushes & verticies around to get it flush, sometimes you can't (short of changing everything).

 

While it's probably better to use a different angle altogether and get things flush, some tricks I used were to overlap the brushes a little (as opposed to leaving a tiny gap or sliver), or actually make the sliver *bigger* so at least it renders, or to bury the whole thing in a new brush which itself doesn't leave a sliver.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

You should, anything that the player won't see, should be caulked. Imagine the backs of buildings that players will never see, they should have caulk applied to their faces. I mean any surface that sees the void is optimized out by the compiler, but anything within the map will be processed during game play (except in some circumstances)

 

If I don't need caulk on surfaces that face the void, and I don't need it on surfaces that are flush against other surfaces (per the "Caulk" writeup), it seems the only surfaces left are ones that aren't flush against other surfaces, and which the player will never be able to see.

 

Maybe a surface that lies inside another brush? Like a beam that ends in a wall rather than against it?

Link to comment
Share on other sites

If I don't need caulk on surfaces that face the void, and I don't need it on surfaces that are flush against other surfaces (per the "Caulk" writeup), it seems the only surfaces left are ones that aren't flush against other surfaces, and which the player will never be able to see.

 

You should not caulk these surfaces, because they are used to cast shadows and caulk does not cast shadow.

 

For instance, if you have a ceiling beam and caulk the upper part (because the player will never look between the small space between the ceiling and the beam running 5cm under it), the beam wont cast a shadow at the ceiling from below, which will look wrong.

 

The only and ever faces you need to caulk are:

 

* faces from func_statics that are flush with a world_spawn or another func_static face.

 

For instance, if you build a table out of brushes, they will split the floor into extra triangles. In this case, you don't need to caulk the leg's lower face, because D3 will optimize it away. But the floor splitting is bad, so you turn the table into a func_static. D3 knows the table can't move, but the faces from the legs flush against the floor are still there. They never cast a shadow, and they are never seen, but the graphics card wil always need to cull them (to cull means "remove from the render list because they face away from the player). Also, D3 will try to use them to cast a shadow, which will be inside of the shadow from the side-faces of the leg.

 

So, caulk the bottom face to give a small performance boost.

 

http://wiki.thedarkmod.com/index.php?title=Caulk

 

(I guess the lower part of that article should be expanded with my explanation)

"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

So, caulk the bottom face to give a small performance boost.

 

 

Do we have any evidence that this boost is actually noticeable? Anyone ever tested a before and after? I have a hard time believing caulking a few surfaces could give any kind of significant performance boost.

Link to comment
Share on other sites

Caulking statics and various other 'never going to be seen but the compiler leaves them in' surfaces benefits both the cpu(more) and gpu(less), while the gain that comes from caulking a single thing is not going to be noticable, once you caulk enough surfaces out you simplify the compiler's output (less work for lighting etc, another gain) and have the benefit of the small gains from back surface caulking, you gain a decent amount on an 'average' optimized map. While in a lot of cases if visportalling is done well and the map has been planned before rushing in, all of this is more of less negligable, it will always help seeing as TDM and doom3 are bound more closely to the CPU than GPU these days.

Link to comment
Share on other sites

Do we have any evidence that this boost is actually noticeable? Anyone ever tested a before and after? I have a hard time believing caulking a few surfaces could give any kind of significant performance boost.

 

It depends on how many of them you have and how many of them are caulk. If you rarely use func_statics, you have not much faces, anyway. A singel table, you can f.i. completely ignore the for leg bottoms.

 

However, if you have f.i. 100 ceiling beams (as func_static, world_spawn doesn't matter!), all of them having a face flush to the left and right wall, you can easily caulk away 200 faces meaning 400 tris in one room. That will make a difference on older cards (esp. if D3 thinks these faces need to cast shadows even tho you never can see the shadow - as it is in the wall. Shadow tris are expensive).

"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

using the mirror shader stacked in line

eg

wall

mirror

glass

room

wall

mirror

glass

room

wall

mirror

glass

room

wall

 

causes some really strange see through walls viewing behavoir as well, both mirror and glass are patches. Mirrors side by side dont cause any problems.

 

I found that sticking caulk behind some patches is not a good idea, depending on the graphics driver version you can see through the caulk behind the patch and the patch displays strange white lines, if you put the same texture as the patch behind the patch then these lines disappear. Altering the number of faces on the patch doesn't solve the white lines problem.

Edited by stumpy
Link to comment
Share on other sites

As for mirrors, as I understand it they render a clone-room behind the mirror. But if the literal-room behind the mirror is in the same portal-leaf it will render too, giving you the see-through effect. You have to make sure the back room is hermetically sealed so they're separate rooms (leafs). I can imagine how having a 2nd mirror in the back room might confuse it for a related reason.

 

I usually put patches on the faces facing the void, which adds up.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

This happens if you are using a very low grid size - it confuses the map compiler into optimizing out surfaces which should remain. Leaving these in a map results in a lot of performance being lost, so always good to find and fix :)

 

As said, try snapping the edges/vertices to grid. (And use a grid size like 1 - you get used to it, just remember the number keys can swap between sizes and it will become second nature to use higher sizes)

 

(And a tip : If you ever _have_ to use something very fiddly and get the issue, you can convert it to a func static (assuming it isnt sealing))

 

newbie here. been going through the DR beginners guide, and i have been using a minimum grid size of 8 for everything so far, which works out nicely and all, but having to constantly switch grid sizes to 1 or 2 in order to manually snap everything in place is a major pain, and the "snap selected to grid" only seems to snap the origin of the brush to the grid. i think i'm not the only person frustrated by the tediousness of snapping and resnapping everything when changes are made, by setting the grid size down, and then zooming in reeeeal far to make sure i'm putting it on the right grid line.

 

So i have an alternative idea. Would it be possible, that in the next DR release, that the "snap selected to grid" feature be revamped into a brand new "snap selected to" which would include the following menu options (hotkeys as well?)

 

1. Snap the origin of selected to grid

 

2. Snap the (highest / lowest) vertex on the (X / Y / Z) axis of selected to the grid.

 

3. Snap the (highest / lowest) vertex on the (X / Y / Z) axis of OBJECT1 to the (highest / lowest) vertex on the (X / Y / Z) axis of OBJECT2

[in this example, OBJECT2 remains stationary, and OBJECT1 snaps onto it]

 

And maybe some other options like snapping origins to vertices of other selected objects.

 

Number 3 is by fart my favorite idea. Because then i could snap the lowpoint of allllll those spoons and forks and plates directly onto the high point of a table.

 

Or, maybe I'm dumb and these options are already available in DR but i just haven't found them. Opinions?

Link to comment
Share on other sites

To be honest, I've -never- had to use snap to grid except when I'm merging parts of maps.

 

It sounds like you're looking for a feature that the Elder Scrolls Construction Set had. It was a "drop to floor" button. But -- If you're fussing with movables, those automatically drop with physics 2 seconds before the mission begins. No need to get ultra-precise.

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

While things are always possible, its unlikely that will happen (well, you know unless you have some coding experience and want to help make it happen ;))

 

You can already snap multiple objects and all of their vertices to grid (select them, hit V, drag a box to select all of them, set grid size to whatever you want, snap) This only really applies to brushes and patches however.

 

I wouldnt worry too much about snapping eeeeeverything all the time, when you're cleaning up an area it might be a good idea or when you are having problems with leaks, but other than that its more or less just a tool to help :)

 

As for a function to 'drop' items origins to a surface, it would be awesome to have something like that - but at the same time its not a real issue to do without. I dont know much of the internal workings of DR's model management, but it might also be very tricky to do.

 

(Back to porting the gtkradiant patches to dr so that one day I might actually have a clue and be useful!)

Link to comment
Share on other sites

To be honest, I've -never- had to use snap to grid except when I'm merging parts of maps.

 

It sounds like you're looking for a feature that the Elder Scrolls Construction Set had. It was a "drop to floor" button. But -- If you're fussing with movables, those automatically drop with physics 2 seconds before the mission begins. No need to get ultra-precise.

 

to snap paintings to grid and apply them, in my experience, still requires a 1 gridline shift in order for the face of the painting to show up, and would not be fixed by a falling effect. Besides, if you apply multiple snaps at once, the idea of "setting" an entire dinner tables worth of utensils and cups / plates to a table in one swift stroke, without ever needing to change from top down view, seems to appeal to my sense of laziness.

Additionally i have not encountered it, but i have read that certain movable objects, if any part of it is under a surface, will cause a sinking effect. maybe not all of these objects are flat? maybe i'd like to set them at an angle? if the very lowest vertex could be snapped into place automatically.... i dunno, seems like a practical idea to me anyway.

Link to comment
Share on other sites

using the mirror shader stacked in line

eg

wall

mirror

glass

room

wall

mirror

glass

room

wall

mirror

glass

room

wall

 

causes some really strange see through walls viewing behavoir as well, both mirror and glass are patches. Mirrors side by side dont cause any problems.

 

I found that sticking caulk behind some patches is not a good idea, depending on the graphics driver version you can see through the caulk behind the patch and the patch displays strange white lines, if you put the same texture as the patch behind the patch then these lines disappear. Altering the number of faces on the patch doesn't solve the white lines problem.

 

Not really sure what you're getting at there, but I think mirrors have to be world spawn and have to be backed by worldspawn.

 

I tried making a fancy standing mirror object and applying the mirror tex to the obect, that caused some weird graphical issues. I also tried placing a brush inside an object frame, I think the brush was func_static'ed and that made some different weird glitches. Either way the brush mirror had space behind it (wasn't sealed to a wall).

Never tried it on a patch but I assume that would also create weirdness.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

to snap paintings to grid and apply them, in my experience, still requires a 1 gridline shift in order for the face of the painting to show up, and would not be fixed by a falling effect. Besides, if you apply multiple snaps at once, the idea of "setting" an entire dinner tables worth of utensils and cups / plates to a table in one swift stroke, without ever needing to change from top down view, seems to appeal to my sense of laziness.

Additionally i have not encountered it, but i have read that certain movable objects, if any part of it is under a surface, will cause a sinking effect. maybe not all of these objects are flat? maybe i'd like to set them at an angle? if the very lowest vertex could be snapped into place automatically.... i dunno, seems like a practical idea to me anyway.

 

Yes, your idea sounds practical to me, too. We should have made all our objects so that if you place them in the editor, their collision model is on a gridline, and the center of the object multiple gridlines above.

 

But sometimes we simple forgot, or the visual model exends slightly outside the collision model (and if the CM sticks into a surface, causing the sinking effect) etc.

 

Your idea of "snap objects to eachother" sounds very much like f.i. Inkscape handles aligning multiple objects. It allows a lot of freedom, you can align them side by side, center by center, top of the first one to middle of the second one etc. You can even add spacing to them (like placing columns with an equal distance to each other etc).

 

Having such a general alignment function would come handy in a lot of cases.

"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

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

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

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...