Jump to content
The Dark Mod Forums

Visportal miss!


ocn

Recommended Posts

I can't get these visportal things to work. It says (as I understand it) to create a brush, place it in a doorway (for instance) making sure there are no gaps, and to texture one side with the visportal texture. Great! It compiles, but the other side of the brush turns pitch black and I can't get back out! I textured both sides, it compiled with a non fatal error, the black side disappeared, but it doesen't affect sound propagation at all- so I'm guessing I'm an idiot... again.:blink:

Where are the REAL brits?! The one's we have are just brit-ish.

Link to comment
Share on other sites

one face needs to be visportal, the other faces need to be textured "nodraw". There is also a super-easy "make visportal" conversion button in the brush menu. Also make sure that the area on either side of the doorway are vacuum sealed. If both sides of the visportal are technically in the same "area", the visportal will break and not even work. If you wish to check visportals, use r_showportals 1 in the console. Red=off, Green=on, invisible=not working.

Link to comment
Share on other sites

one face needs to be visportal, the other faces need to be textured "nodraw". There is also a super-easy "make visportal" conversion button in the brush menu. Also make sure that the area on either side of the doorway are vacuum sealed. If both sides of the visportal are technically in the same "area", the visportal will break and not even work. If you wish to check visportals, use r_showportals 1 in the console. Red=off, Green=on, invisible=not working.

 

Incredible! It works. Thanks! :D

Where are the REAL brits?! The one's we have are just brit-ish.

Link to comment
Share on other sites

Red = closed (nothing being rendered on the other side), Green = open (stuff is being rendered) and invisible = not working is probably an easier way to understand it :)

Intel Sandy Bridge i7 2600K @ 3.4ghz stock clocks
8gb Kingston 1600mhz CL8 XMP RAM stock frequency
Sapphire Radeon HD7870 2GB FLeX GHz Edition @ stock @ 1920x1080

Link to comment
Share on other sites

Oh, and remember textures/common/caulk texture.

 

It is a texture which gets not drawn in game. A good way to save polygons.

 

When you make your first window, make sure all the surfaces the player will never see are caulked. After that, make the window into a func_static and start cloning it everywhere. It might sound silly, but it is really smart thing to do: each rectangular surface you caulk saves 2 polies.

 

Math: you have a window which consists of the panel brush and 4 brushes which make the frames. If you caulk the 5 surfaces which touch the wall (player never sees these) you save 5*2 = 10 polies. And your scene which contains 100 windows is 1000 polies cheaper. If you apply caulk in all such objects you'll save even more, meaning that you can build more complex scenes.

 

I learned caulking just recently and want to share this wonder.

 

Also remember to turn non-void sealing detail objects into func_statics. Note that func_statics in which the AI can bump into need monsterclip brushes to surround them. The func_static conversion saves you also a lot of polies. You can easily check the effect by making 2 worldspawn walls and putting a func_static window and a worldspawn window on each of the walls. When you look at the wall ingame r_showtris 3, you can see that the worldspawn window causes the wall to be divided into larger amount of polies.

 

These kinds of technical things should be learned quite early, because it allows you to build technically more advanced scenes, saving you the trouble of optimizing you map before release. Optimization is boring work so it's clever to avoid it by building smart.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Oh, and remember textures/common/caulk texture.

 

Yes, I just read a little about it. I don't think I quite grasp it yet, though. I may understand how it might be benefitial to transparent objects like windows, but don't the geometry need to be calculated even if it is invisible in such a case? And would it also be of value to caulk the outside walls of a room that would never be visible under any circumstance?

Where are the REAL brits?! The one's we have are just brit-ish.

Link to comment
Share on other sites

And your scene which contains 100 windows is 1000 polies cheaper.

 

Which is about 20% of a single AI, or 0.7% of a detailed 150,000-poly scene. So it may be worth doing in certain cases, but isn't going to offer any miracles.

 

Reducing the area of overdrawn geometry -- the number of on-screen pixels that are rendered multiple times due to excess lighting, patches overlaying brushes etc -- is probably more important than reducing polycounts. Caulking can help with this as well, but is unlikely to be worth doing if the size of the brush is small.

 

Also remember to turn non-void sealing detail objects into func_statics. Note that func_statics in which the AI can bump into need monsterclip brushes to surround them. The func_static conversion saves you also a lot of polies.

 

Again, it's not a simple as that. While reducing polies, you are also increasing the size of them, which could in fact increase the amount of overdraw. The "excess" polygons you see with r_showTris might in fact be helping to divide up geometry along light boundaries.

 

As with all optimisation techniques, it is important to remember that framerate is king. Spending two hours applying a manual technique that doesn't result in any noticeable change in framerate is generally a waste of time.

Link to comment
Share on other sites

I may understand how it might be benefitial to transparent objects like windows,

 

Probably you never want to like it in windows. If you want a tansparent window, you do not put any brush there. If you want to have window, which cannot pass, use nodrawsolid.

 

but don't the geometry need to be calculated even if it is invisible in such a case? And would it also be of value to caulk the outside walls of a room that would never be visible under any circumstance?

 

I think The Engine caulks automatically the worldspawn surfaces which touch the void. If you noclip ingame into the void you can see into the map, you do not see the textures on the worldspawn exterior surface.

 

If you transform an object into func_static, then all the surfaces are always drawn and the engine does no automatic caulking. That's why you caulk the surfaces newer seen to the player.

 

And remember to NOT caulk 'invisible surfaces' like table bottoms or something like that. They might cast incorrect shadows then. Caulk only surfaces which touch the walls or something else, surface which the player cannot see in any circumstances.

 

7134739.png

 

See the image. The left one shows the window from inside the room. The right image shows the same window seen from the direction of the wall. The wall has been removed for clarity.

 

If I didn't have the caulk on these surfaces, the game would have to render them even the player can never see them. For one window it does not matter much, but once you have many such objects the poly savings are getting quite high.

 

 

As with all optimisation techniques, it is important to remember that framerate is king. Spending two hours applying a manual technique that doesn't result in any noticeable change in framerate is generally a waste of time.

 

I agree. That's why its good idea to put caulk on the objects before the mapper starts cloning the objects. It takes few seconds to apply caulk on the object and once it is the caulked object you clone around you get easy optimization without large amount of excess work.

 

Thanks for the clarifications, though. I didn't know polygon size is so important.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Which is about 20% of a single AI, or 0.7% of a detailed 150,000-poly scene. So it may be worth doing in certain cases, but isn't going to offer any miracles.

 

Reducing the area of overdrawn geometry -- the number of on-screen pixels that are rendered multiple times due to excess lighting, patches overlaying brushes etc -- is probably more important than reducing polycounts. Caulking can help with this as well, but is unlikely to be worth doing if the size of the brush is small.

 

I'd just like to inject that caulk faces do not casting shadows, and saving the shadow cast will have much more performance impact than the surface itself, since polygons facing away from the player are never drawn, anyway. So if you have a shelf standing on the wall, the backside shold be caulked, because:

 

* it takes extra time to decide not to draw it

* it casts a shadow that can never be seen (and I don't think D3 optimizes these away, as it cannot know if you move the func_static later away from the wall, or not)

 

Just saying, the final remark from Orbweaver is basically spot on, except for the fact that if FPS is not different on your system, doesn't mean it might get better on an older system (or use less memory, and thus load the map faster).

"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

I learned caulking just recently and want to share this wonder.

 

This used to come up all the time in the early years of TDM, and I recall a number of people saying that caulking was not worth doing in most cases. Has anyone ever done a FPS comparison to show that it is actually worthwhile?

Link to comment
Share on other sites

From my experience the gains aren't immense in most cases.

 

However there's no reason to not do it as it is easy if done correctly (caulk and object before cloning 10 times) and every little bit can help.

 

Tris cost processing power, tris cast shadows, shadows cost processing power...

 

Maybe saving 1000 polys is only a 10th of an AI - more like a 5th.. but still, that's 1000 more polys you can use for visible details and have the SAME performance. Would you rather have an extra 1000 visible or 1000 hidden faces? There will come a time when that comes in handy whether or not it's absolutely critical.

Same reason most models are lower poly than they really need to be... it's called optimization.

 

Also my favorite reason for it is you can filter caulk, which leads to being able to see your scene much better when working on it.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Maybe saving 1000 polys is only a 10th of an AI - more like a 5th.. but still, that's 1000 more polys you can use for visible details and have the SAME performance.

 

That's my point, though. Does saving 1000 polys have any impact on performance at all? With models, saving 1000 polys is significant because a mapper might put a dozen models into a single scene. How much caulk do you have to use to save 1 FPS on an average system?

 

Personally, I wouldn't spend more than an hour doing something that will boost things by only 1 FPS, and the amount of caulk I've seen in some maps looks like it took a lot longer than that.

Link to comment
Share on other sites

7136159.png

 

This is faulty setup, read the next one.

 

There:

I did a caulked and noncaulked version of the Knighton Manor start. In the caulked one I've caulked all the visible func_statics from surfaces the player cannot see in any circumstances. I also added some AI's to choke my computer. The both situations were taken from a player start shown in the image. Starting position was exactly the same for both maps. Mouse was not moved. I only crouched in both cases to make sure I can do my experiment unseen.

 

Performance breakdown:

 

NO CAULK:

Views: 5, draws: 1860, tris: 295 000, shdw: 50500, image 108.5MB

Rate: 29fps.

 

CAULK:

Views: 5, draws 1850, draws: 293 000, shdw: 50500, image 107.9MB

Rate: 31fps.

 

Please note that all the values drift quite a bit due to AI's fooling around with the lanterns and drinking. I'll redo this later without those props. But the values I took were the minimums I observed in the drifts.

 

Basically this shows that very simple caulking does have a slight performance increase. I wouldn't advise people to start caulking objects they already have in their maps, but I recommend that before cloning objects, it would be good idea to spend 5 seconds to apply caulk on the unsees surfaces. When you have many of such objects visible, slighly better performance will be gained when your source func_static is properly caulked.

 

To answer Springs question, I had to caulk following objects to get few fps more:

20 windows

2 torch holder metal squares

1 statue footer

few tens of meters of hedge

2 wooded supports

2 chimneys

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

* it casts a shadow that can never be seen (and I don't think D3 optimizes these away, as it cannot know if you move the func_static later away from the wall, or not)

 

As far as I am aware, the back face of a shelf against the wall will only cast a shadow if there is a light behind it casting a shadow forwards into the room, since triangles only cast shadows in the opposite direction to their normal. A light in an adjacent room will only count if there is a direct line-of-sight-through-portals connection between the two rooms, otherwise the shadow volume will be optimised out (although this optimisation might be for worlspawn only).

 

NO CAULK:

Views: 5, draws: 1860, tris: 295 000, shdw: 50500, image 108.5MB

Rate: 29fps.

 

CAULK:

Views: 5, draws 1850, draws: 293 000, shdw: 50500, image 107.9MB

Rate: 31fps.

 

I would consider a 7% performance gain from a 0.7% reduction in geometry highly unlikely. As you say the frame rate was very variable due to the actions of AI and other game functions, and this is most likely what is giving you these numbers. You would need to use the timedemo function to exclude AI to get a usably accurate result.

Link to comment
Share on other sites

You would need to use the timedemo function to exclude AI to get a usably accurate result.

 

Howsabout if I use killmonsters and replace the choking AI's with ragdolls to bring in more polies. Trying it now.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Okay that was a good idea. Now the values were rock-solid with very, very low variance. I could take really accurate data.

 

Scene:

7136874.png

 

I removed the guards and put 16 ragdolls in the scene. After the map loaded the corpses came tumbling down (a mighty spectacle indeed). I killed the living AI's in the map with killmonsters. The I waited some 5-7 minutes until the fps did not improve anymore (ragdoll physics relaxing). Then I recorded the data.

 

Performance:

 

NO CAULK:

Views: 5

draws: 1812

tris: 292470

shdw: 40842

image: 87.5MB

fps: 36-37

 

CAULK:

Views: 5

draws: 1803

tris: 291440

shdw: 40710

image: 86.9

fps: 36-37

 

Yep, looks like the people who say caulking is useless for fps gain are correct. Still we observe roughly 1000 tris saved by the caulking proces. These 1000 tris weight 0.6MB in memory and a few more draw(call?)s.

 

It might be useful to see how many tris are needed to be increased to make a solid effect on the fps count. This could be done easily by adding more ragdolls. This would yield the extent of polies saved by caulking in order to have an effect on the fps counter. That is, if the polies in the ragdolls are handled similarily as the func_statics caulked.

 

I'll add a few more and see what happens.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

According to id (and received wisdom about GL rendering), the number of draw calls is more important than the number of polies alone. So the impact of adding more polies will vary depending on the texture applied (same texture as surrounding geometry == fewer extra draw calls), and its relation to other geometry (i.e. worldspawn brushes with the same texture can be submitted as a single batch, func_statics are submitted independently).

 

I think somebody did some tests a while ago comparing single-textured models against multi-textured models, and discovered a minor but noticeable difference because of this factor.

Link to comment
Share on other sites

This time I added 2 ragdolls into the scene and repeated the last test.

 

Now it looks like this.

 

NO CAULK

views 5

draws 1885

tris 315690

shdw 43372

image 87.5MB

fps 34-35

 

CAULK

views 5

draws 1878

tris 314580

shdw 43218

image 86.9

fps 34-35

 

Some conclusions of my fun little experiment (unless someone points some mistakes in the setup):

So 2fps drain was caused by addition of roughly 23000 tris, 75 draws and 2500 shdw. That would be basically a lot of windows with 5 caulked surfaces. Each surface caulked saves 2 polies. That's 10 polies per window. Caulking 2300 such windows would yield a 2fps benefit. :o

On my computer, that is. Lowend systems might still benefit from lower amount of caulking.

 

Adding ragdolls do not drain memory, because one model is loaded only once.

 

However, it looks like surface caulking has a memory saving benefit: caulking (and elimination of) 1000 tris saves 0.6MB of memory! How significant this is I leave to computer geniuses to comment.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

As far as I am aware, the back face of a shelf against the wall will only cast a shadow if there is a light behind it casting a shadow forwards into the room,

 

No, in D3, backward faces cast shadows. (you can easily try this, add a ceiling bar 5 units below the ceiling and caulk its topside, lights placed under the bar will no longer cast a shadow on the ceiling). So if you have a light in front of a desk, the backside of the desk will cast the shadow *towards the wall*. Since the backside is flush with the wall, the shadow will never be seen (and I think the engine has no way to know this, so calculates the shadow anyway).

"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

Yep, looks like the people who say caulking is useless for fps gain are correct. Still we observe roughly 1000 tris saved by the caulking proces. These 1000 tris weight 0.6MB in memory and a few more draw(call?)s.

 

Remember, it is drawcalls *per light*. If your entity is hit by 5 lights, you save 5 times the drawcalls, that can make quite a difference.

 

As you said, 1000 tris, or 10 drawcalls more, or less, doesn't make a difference. And certainly does not warrant 2h work. However, even all these small things can add up.

 

It might be useful to see how many tris are needed to be increased to make a solid effect on the fps count. This could be done easily by adding more ragdolls. This would yield the extent of polies saved by caulking in order to have an effect on the fps counter. That is, if the polies in the ragdolls are handled similarily as the func_statics caulked.

 

That really depends. First, it is not only the number of tris, but also "how often is each tris hit by a light"? Also, tris with a new texture might issue another drawcall, which is a major slowdown factor. And then there is tris size. Very very small tris (< 1 pixel) still need to be rendered, and to get correct anti-aliasing, the graphic card samples points at the tris border multiple times. That means with a 1x1 pixel tris, the pixel might get shaded 16 times, whereas with a 100x100 tris, every pixel gets shaded on the average 1.00001 times.

 

And then there is the whole hardware side. If your GPU is already fillrate limited, adding more pixels to shade will kill it. But if it isn't fill-rate limited, you can add a lot of pixels and the performance will stay the same (the card just uses more power and heats your room more). Likewise with tris, if the card is already on the limit on how many tris itcan push, adding 1000 more will kill it. If it isn't near that border, you will only see a tiny difference because the CPU needs to push the extra tris to the GPU.

 

So, basically, the only thing you can conclude is that "less work for GPU and/or CPU will result in speedups." How much is hard to predict, and almost impossible to measure (unless you force everyone to usethe same machine as you test on :)

 

Not to discourage you, but any result you get can almost not be replicated on another hardware. The basic advise would be: "If you don't get at least 20% speedup, don't bother." However, as I said, 10 times 2% speedup is also 20% speedup, so don't discount small steps.

"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

According to id (and received wisdom about GL rendering), the number of draw calls is more important than the number of polies alone. So the impact of adding more polies will vary depending on the texture applied (same texture as surrounding geometry == fewer extra draw calls), and its relation to other geometry (i.e. worldspawn brushes with the same texture can be submitted as a single batch, func_statics are submitted independently).

 

I think somebody did some tests a while ago comparing single-textured models against multi-textured models, and discovered a minor but noticeable difference because of this factor.

 

That was me (or at least I did that test, too) and I think it was posted in the thread with the LOD models. A model with two shaders issues two drawcalls per light, one with one shader one drawcall per light. That can make a lot of difference, so it is wise to make texture atlases for models (when possible and when sensible, of course :)

 

(The improved idtech4 engine even makes the texture atlases for you, where all textures for a special model are combined together into one giant texture. Wolfenstein - Enemy territory was I think the engine where I did read about this.

"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

    • 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.
      · 2 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...