Jump to content
The Dark Mod Forums

Newbie DarkRadiant Questions


demagogue

Recommended Posts

Each material in a scene counts as one draw call, so the number of textures per visleaf does have a performance impact there.

As for the whole map? Well, the "image_preload" arg makes it so that all these textures load into the video card's VRAM. The more

textures in VRAM, the more time it takes to "find the texture" in memory space... though I think most DX10 and higher cards have

good caching structures for this. Still, most modern engines have gone to "texture atlas" (multiple textures written to the same file)

approaches to reduce draw calls.

 

I'm not sure where Biker found his sweet spot but he's got enough testing data to fill a good few spread-sheets (if he kept it organized... ) :laugh:

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I guess the problem applies if the amount of VRAM needed is highe then the VRAM provided by the graphics card. In this case I guess the graphics card uses the RAM on the mainboard, too, which would definetely decrease performance due to higher access times. But this is hard to nail down to a certain number, as the size of the textures matters.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Not only that, but you would have no way of knowing how many textures are being used by the models in your map.

Link to comment
Share on other sites

Just what's on worldspawn/fs (I'm using the map -> map info menu to count). I can probably ignore stuff like nodraws and caulk though...which would help get me under the 500 count.

 

There's no actual cap; it's definitely not like the entity count limit, for example. All big maps have lots more than 500 textures loaded through models anyway, so probably no need to change stuff in the map to avoid a limit. Any performance effect from more textures would be small and gradual, even if memory might be an issue on some cards. As Obs said, that's the only thing that could be affected. And I think that our engine downsizes textures rather than overspilling into main memory.. If that's right then performance would be just as good on those cards too. It's close-up detail in the textures that would be sacrificed.

Link to comment
Share on other sites

I got a problem, that I have absolutly no idea what it is caused by:

 

When dmapping I get the following warning (twice, with a little different numbers):

brush 1214 on entity 0 is unbounded (-3064.00  360.99  219.99) - (-3046.96  368.02  260.00) - (17.04  7.03  40.01).

Ingame I added visportals to towerstairs before that warning, running along an octagon (two sides of it). The lower one worked, but the ones in two other stories did not. The visportals were composed of two parts. One of the parts of the two upper ones was see through when playtesting it. I deleted one of the offending parts and made it new, but the error persisted.

 

But deleting those visportals didn't remove the warning.

 

I couldn't find anything offending when treating each set of the three numbers as coordinates.

 

 

How can I find out what is causing this warning, any hints?

(And if it maybe isn't related, any idea whats wrong with my visportals?)

Link to comment
Share on other sites

Try finding the offending brush (by going to map -> find brush) and turning it into a func_static. I had something similar happen to my WIP with a random brush (which thankfully wasn't sealing geometry, a portal, etc), and when I turned it into a f_s the warning went away.

But you should walk having internal dignity. Be a wonderful person who can dance pleasantly to the rhythm of the universe.

-Sun Myung Moon

 

My work blog: gfleisher.blogspot.com

Link to comment
Share on other sites

If the offending brush can't be made into a func_static, put the brush back on the grid (even 0.125 should work).

 

This problem can pop up at any time, especially after saving and reading the same map a number of times.

 

I've mostly seen it happen with steps in a homebrew circular staircase.

 

If snapping to the grid doesn't help, delete the brush and recreate it.

Link to comment
Share on other sites

Try finding the offending brush (by going to map -> find brush) [...]

If the offending brush can't be made into a func_static, put the brush back on the grid (even 0.125 should work).

 

This problem can pop up at any time, especially after saving and reading the same map a number of times.

 

I've mostly seen it happen with steps in a homebrew circular staircase.

 

If snapping to the grid doesn't help, delete the brush and recreate it.

Interesting.

The function helped, wish I had known before about "Find brush" would have saved me a bit of time :-) - well learned something new.

Interesting enough I tried fixing all those brushes that were a tiny bit off (those .000001) and the brush that did the problem wasn't affected when viewing it in the browser it seemed. Snapped it to grid anyway, moved it abit around, snapped to grid again, moved it back and the warning is gone.

So one less problem.

Big thanks to you two :-).

 

Sadly that didn't save my visportals.

Any idea what could be the problem with them?

 

Are visportals of more than one brush a problem? (on the bottom opening it works, otherwise i would have thought thats definitly the problem)

Could it be related to the fact that the roof must be leaking? (but not external)

(Haven't got around to finding and fixing the leak, as the roof is a bit complicated with this building, and I am glad for the moment that it looks right.) Edit: Fixed it now together with one other work I have done one more of the visportals shows right.

 

One of the mssing parts after mapping seems to be replaced by a skyportal view, which is not touchable (I fall through to the stair below), the other is see through too, but does show the map below when viewed from above, minus the walls it touches. It also can be walked upon. Edit: Outdated

 

Edit: Okay, so the visportal I could walk upon had caulk on the outer sides, no idea how it got there, but I checked all sides to be sure all they were done right. Fixing that didn't fix the visportal though. After working through a few rounds of fixing all the internal leaks in the roof (and finally just raising all the walls a small bit), the upper visportal is working now too.

The middle visportal (part of it) is the last offender, still showing a skyportal, although from above it turns completly black most of the time.

The remaining part works correctly as a visportal.

Edited by DeusXIncognita
Link to comment
Share on other sites

Visportals made from more than one brush should be ok. The visportal faces have to touch along the edge to make the seal, and they'll open and close independently, if the player can see only one of them. Any chance of a screenshot of the offending VP in DR? I'm having trouble picturing it.

Link to comment
Share on other sites

The visportal faces have to touch along the edge to make the seal, and they'll open and close independently, if the player can see only one of them.

 

 

Wait, what?

 

You can make visportals out of more than one brush and they'll open and close independently of each other??

Link to comment
Share on other sites

 

Wait, what?

 

You can make visportals out of more than one brush and they'll open and close independently of each other??

 

I thought so but now you have me doubting!

 

I just tried it and they're not independent after all. Both open or close in unison. I remembered linking the two faces of a 2-brush portal using func portal entities in a map I'd made last year, but think that must have been because I wanted them using the same LOD-controller rather than because they were opening and closing independently.

Link to comment
Share on other sites

So if you take one visportal and cut it in half, can you put different func_portals on each half that close them at different ranges?

Link to comment
Share on other sites

Visportals made from more than one brush should be ok. The visportal faces have to touch along the edge to make the seal, and they'll open and close independently, if the player can see only one of them. Any chance of a screenshot of the offending VP in DR? I'm having trouble picturing it.

Have made screens of it, and have a bit more info:

The screenshot made in Darkmod is quite dark (and made from below), but when I made it with the light on the offending part wasn't visible on the screenshot. (and the ones from above showed less of it)

It was visible ingame though.

Also the black part lookes like the sky IF the door below was open (and therefore a connection to the outside was there), but this also didn't make it to the screenshot.

 

The highlighted Part in Dark Radiant is the one having the problem.

 

 

KgLVZjf.jpg

tyLPSop.jpg

Bs2M1za.jpg

 

 

Edited by DeusXIncognita
Link to comment
Share on other sites

Eep! That looks like the express train to Troubletown!

 

What I would do is to keep ALL visportalled worldspawn holes square. Square. Always.

 

Make a square hole on the ground. Apply a single square visportal on it. Make the extra geometry func_static. If the AI needs to walk on it, monsterclip appropriately. Never design geometry that requires you to use non-square visportals and non-square worldspawn geometry. Only madness and chaos awaits you in that direction!

 

And they bite HARD!

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

You can use a square visportal in a non-square hole. There is nothing wrong with visportals clipping into worldspawn in most cases. Or you can make the floor func_static as Sotha suggested and then there's no issue at all.

Link to comment
Share on other sites

So if you take one visportal and cut it in half, can you put different func_portals on each half that close them at different ranges?

 

Yes, apparently (I just tried it). Although to test you it you have to set one of the portal distances very close, because you won't see that it's closed using r_showportals. It'll look green whenever the other one is open. But if you set the distance close and walk up to it you'll see that nothing behind it is rendered until you get within the right distance.

 

That sounds like what's happening with your stairwell DeusXIncognita... one of the portals must be stopping anything behind it being drawn, which means you get to see skybox. (the skybox gets drawn over the whole screen every frame before anything else in your map is drawn).

 

You could try using a single portal to fill the gap (it doesn't matter if a chunk of it overlaps or sticks into your floor).

Link to comment
Share on other sites

That has interesting implications for wide city streets. They require big visportals, but if you can split them up and independently control each part, there may be some benefits there. Or maybe not...I'm having trouble visualizing this.

 

Ok, in the image below, the pink lines are visportals and the blue are worldspawn. Let's say the bottom visportal is cut in half and the side on the right is forced closed by a func_portal. When the player is standing in position "X", they can see through the left half...does the fact that the right is closed actually block the top visportal, closing it?

post-9-0-55841600-1429804647_thumb.jpg

  • Like 1
Link to comment
Share on other sites

Let's say the bottom visportal is cut in half and the side on the right is forced closed by a func_portal. When the player is standing in position "X", they can see through the left half...does the fact that the right is closed actually block the top visportal, closing it?

It seems so. Here's your test case in DR:

 

post-29566-0-23211800-1429809800_thumb.jpg

 

The foremost portal is the split one. You can see I've bent it*. Behind each portal is a barrel so that we can see what's rendered behind walls using r_showtris. Behind the right half of the split portal is a torch for the same reason.

 

With no func portal entity, when you look at the rear portal through the bent one, it's still open, and the rear barrel and the torch on the right are drawn even though they are hidden behind the wall in the foreground:

 

post-29566-0-68117300-1429809799_thumb.jpg

 

With a func_portal attached and set to close at 50 units distance, the rear portal is closed and the barrel and light are not drawn. You can see the left half of the portal is open (its barrel is visible) but the right half is closed (no light) and the rear portal is closed too.

 

post-29566-0-97010200-1429809798_thumb.jpg

 

* In fact I had to bend it to get it to work as a portal at all. But I've another more complicated test map where coplanar split portals work ok. Before I bent it I had the same problem as DeusXIncognita: nothing drawn behind the portal. I don't know why I had to bend this one.

  • Like 1
Link to comment
Share on other sites

In such a case you would normally place another vp in the small road.

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

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Well, that's excellent then. I don't really understand WHY that works, though. What would happen if the left part of the visportal wasn't even there? Would half a portal still work if you're closing it with a func_portal?

Link to comment
Share on other sites

When I try it with just half a (func) portal, it blocks off the whole street.

 

post-29566-0-23882700-1429827034_thumb.jpg

 

Now this next bit is interesting... split portals do work independently after all, with or without a func portal. When I add another portal at the end of the passageway like Obs suggested, so it can hide the right half of the portal, it closes. You can see the absence of the barrel and torch. This is an ordinary split portal, not a func portal.

 

post-29566-0-74504000-1429827033_thumb.jpg

 

The confusion comes in because r_showportals isn't quite doing its job right. A portal can be closed in the sense it's blocking rendering and closing portals behind it, while showing up green in r_showportals.

 

Confirmed... I looked up the r_showPortals code. It draws after the main scene rendering, and when it chooses whether to colour a portal green or red, it's not actually testing whether the view flowed through a specific portal, it just tests whether the visleaf the far side of a portal has had anything drawn that frame. So a portal can be blocking the view but still look green:

if ( portalAreas[ p->intoArea ].viewCount != tr.viewCount ) {
    // red = can't see
   qglColor3f( 1, 0, 0 );
} else {
   // green = see through
   qglColor3f( 0, 1, 0 );
}

That must mean that all portals leading into a given visleaf (from where the player is standing) will go green or red at the same time whether or not the player's view really passed through that portal. The code that does the real rendering is more sophisticated. It cuts down the player's view frustum as it passes through each portal, and only continues flowing through more distant portals if they can be seen through the nearer portal.

  • Like 1
Link to comment
Share on other sites

I tweaked r_showPortals in my test build so it distinguishes between portals that've been seen through and those that merely face on to an open visleaf:

// green = we see through this portal
// yellow = we see into this visleaf but not through this portal
// red = can't see

post-29566-0-58415400-1429831030_thumb.jpg

post-29566-0-84629800-1429831029_thumb.jpg

 

The second one is the more complex portalling in NHAT cathedral.

 

I'll see if I can spot what was going wrong when the coplanar portals were misbehaving before I misaligned them. Quite possibly the same error as with the stairwell above.

Link to comment
Share on other sites

Eep! That looks like the express train to Troubletown!

 

What I would do is to keep ALL visportalled worldspawn holes square. Square. Always. [...]

You can use a square visportal in a non-square hole. There is nothing wrong with visportals clipping into worldspawn in most cases. Or you can make the floor func_static as Sotha suggested and then there's no issue at all.

Thanks. I have no way to make the visportal square, as it would be way to large (as far as I know visportals channel sound, so it should take the right way and not come directly through the floor.) and also reach the outside.

But I made one visportal out of it, a bit larger than the two before, only cutting slightly into the room itself.

 

Good to know about the geometry too, too late for that one, and sad for geometry that nonesquare works badly.

No idea how I should do an octagonal tower with squares.

Well, it will be my only one falling out of standard architecture I think, so I'll see how it works I hope.

Chaos hopefully then only in that area if there is one.

 

I take too long to decide on architecture anyway, doing it again would take too long.

 

Nice to know about all the other things too, might help with other visportals that they trigger independant of each other even when touching (and that r_showPortals doesn't show how it works exactly.)

 

Thanks for the help, another step solved on the way to a mission.

(Damn mind, not knowing how to stop architecture from needing another house / wall etc. I will learn I hope, I have many great missions and their authors do learn from. But this point I only learn slowly it seems.)

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  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • 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
×
×
  • Create New...