Vis work Titanic

[AngelModder]

Ok so I have a few questions concerning vis and the proper procedure I should take with the Titanic project. I've included a picture to better explain my question. Alright to get into the details of how and why this ship is the way it is. Firstly the ship has what is called a "sheer", to best explain this you would have to look at the ship from the side profile, it's higher at the bow and the stern (ten feet or so at bow), and about 5 feet at the stern, with the 75 feet where the engine sit between funnels 3 and 4 being the only level plane. The reason this detail is included is simply that NOTHING lines up right if you don't, it really messed with the layout as well as just in general how she looks. Alright so to pull this off the ship has been built in 50 ft long X 92.5 feet wide sections, all but the 100 feet where the engines sit (I upped it as the angle was so slight in the extra 25 feet it was useless).
The very bow is a 25 foot piece and the superstructure tail is 33.9 feet however that's not really important in this question, but the overall measurements are. So what I did was the keel (belly of the ship in your eyes), stays level, while the rest of the decks and hull slowly angle up every 50 feet, this was done by the power of two on grid size two to avoid any error while at the same time following her line plans to ensure accuracy. A Very effective visual effect. All of this information I am feeding you is so you better understand the circumstances being dealt with. All the floors and ceilings were 1 grid 8 thick, so ceiling 8 floor above another 8 and so on and so forth all the way down. this as to enable the use of hint portaling on the interior in her hallways etc.
Now, in this example you are looking at the A Deck Promenade area, this would be an external area of this ship, where passengers could walk from one end to the other without interruption. In this photo you will notice the basic block structure of the deck housing (structural bs for the interior), now the one selected there will be no interior, in fact allot of A Deck will have no interior, so the top beam work I've allowed for the moment to run through the said brush from one side to another to reduce brush count.
Now the question is how some things SHOULD be done.

A: should these beams be cut so that they don't go through the deck housing brush to disable the from side to the other drawing.
B:The floors and ceilings and deck housing are set to structural, the beams detail. Should in that case the deck housing walls, ceilings, and floor be cut down the middle to aid in the disabling from one side to the other drawing, since at this moment you'll be drawing both sides even while on the other?
C; If so is there any proper procedure or thing's I should take into account? To cut the said beams and etc will up the overall brush count (not too worried about that atm but am trying to avoid more then 12k for this entire project). If so taking into consideration how this is all built and needs to be built for this design to work, how would I hint this?

I'll admit I SUCK at vis work and am trying to grasp it as I go to make this project stable. So please try to term things in a lamens way.
One thing to possibly keep in mind is at this moment the outboard wall (far left wall in photo), is a patch mesh, this is so all the windows etc can be done via a texture and avoid hundreds of extra brushes that would suck up even more tris, and just honestly never look as good.

Does my grammatical structure meet your standards now? @@mrwonko
 

Example

 

 

 

 

Please note all textures and graphics you see are temporary as the whole thing is under construction.

AngelModder™

[mrwonko]

If you could insert some paragraphs I might actually read that.

[AngelModder]

Wow rude...

[AngelModder]

Alright so I did some playing around, however I've found some issues. I've managed to stop the beams and the deck housing walls on the opposite side from drawing by cutting it all down the middle and cutting/adjusting the beams to line up against the deck housing. However I still find that part of the floor, ceiling and that outboard mesh still draw? Does this require some sort of hinting? If so how should I apply this appropriately?
I've also noticed that the brushes from the deck above (or below depending on where I go) still draw even though the ceiling of the deck below and the floor of the deck I am on are two different brushes. Again what am I doing wrong?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[mrwonko]

Wow rude...

Possibly. I didn't mean to be, I was just being honest. I will not read over 3000 characters without a single line break, that's unnecessarily exhausting. Thanks for inserting some.

 

Now it's at least somewhat readable and the only problem is the abundance of ship lingo I don't fully understand, which I suppose naturally comes with such a project, and a failure to get to the point.

 

Am I correct in summarizing your problem thus: "I have beams going through multiple rooms, should I cut them at the walls so parts in other rooms need not be drawn or should I use a single brush to keep the brush count low?"

 

If so, that's somewhat hard to tell but probably won't matter much either way in the end, proper usage of detail and structural brushes is much more important. Focus on getting that right and maybe upload your map to let some experienced mappers take a look and give you hints.

 

 

To debug vis work, you can compile with -saveprt and use the Radiant's prtview plugin to take a look at the generated portals.

[AngelModder]

Possibly. I didn't mean to be, I was just being honest. I will not read over 3000 characters without a single line break, that's unnecessarily exhausting. Thanks for inserting some.

 

Now it's at least somewhat readable and the only problem is the abundance of ship lingo I don't fully understand, which I suppose naturally comes with such a project, and a failure to get to the point.

 

Am I correct in summarizing your problem thus: "I have beams going through multiple rooms, should I cut them at the walls so parts in other rooms need not be drawn or should I use a single brush to keep the brush count low?"

 

If so, that's somewhat hard to tell but probably won't matter much either way in the end, proper usage of detail and structural brushes is much more important. Focus on getting that right and maybe upload your map to let some experienced mappers take a look and give you hints.

 

 

To debug vis work, you can compile with -saveprt and use the Radiant's prtview plugin to take a look at the generated portals.

I must respectfully disagree with the idea of uploading it as of yet. I'm sorry but I trust very few, I've had thing's stolen in the past, not that this has much monetary value but the point remains, good idea though IF I found one I trusted. I might trust @@Lazarus and a few others but not many.

 

Any ways yes you are correct Sir, and as you can see from the post above your own I did follow my instinct and cut the brush. I pulled the whole section into a separate map to toy with the idea. So far it's much better, but I am unsure as to how I should appropriately apply any hint's that may be necessary, or if I have done some thing unnecessary or wrong. That is why I even posted a GTK shot for some one to draw on and said "hey this can be put back together or hey cut this etc etc".

 

Regards - AngelModder™

[Oobah]

Once you release any content it is no longer fully in your control.

 

As for -vis I'll give you few things to aid you.

 

-vis stage is more or less a finer calculation of map portals after the initial map .bsp is compiled.  If the portals get messy and you have vanishing walls, it's due to the portal calculation.  Simply put, clean up your mapping.  Detail more or less anything that isn't the core wall/floor/ceiling.  That means beams, trims, and fancy brush work that doesn't connect the core map to the void outside the level, detail brush it to aid in the portal calculations.

 

1. Manual hint brush work is REALLY not needed.  The game does fine with the portal calculations. 

2. Portal generation in a cube aka box is easier.  When you have a lot of randomly curved surfaces the portals try to calculate out its way around them and can cause little issues here and there.

3. If you have two cells connected together, not in the form of doors but such as windows.  Like an exterior window to an interior cell.  The exterior cell portals that are calculated will be apart of the interior ones.  Which leads into 4.

4. Portals calculate things that are viewable.  If you have more detail brushes, but an exterior piece of caulk to just calculate out a pure box with the randomly jutting walls as detail.  The portals can become very simple and render distant brush work more so regardless of say, you're away from a window or next to it.  Takes a bit of experimentation BUT it's what you have to deal with mapping on something like this.

 

Newer games have more rendering of far away detail and such, but this is an FPS engine.  Work within the limitations, don't plow through them.  This is why lot of maps made with big flashy exterior work was a waste of effort.  If the people researched they could of done something as effective without any impact on the map FPS.  MT I did for example did that.

 

For manual hint brushing a simple thing you can do is put it around areas where the hallway bends into another portion.  It may still render part of the wall in the distance BUT it will not render as much of the entire area.

 

If you have everything contained in a SINGLE cell, it will most likely render everything in that cell regardless of its distance from you.  This is why you're better off isolating cells to specifics.  This is more so for large exterior cells, which really aren't needed.  If you have a whole map contained in a single cell, which means windows going into hallways, etc.  It renders area portals more or less useless and not effective in the least.

 

You can render the portals generated in game, but due to Radiant being able to do it, can cut out the testing time to see where the hiccups might be.  But sometimes a test of a basic compile can be helpful also to see what is not fully working right.

 

At a certain distance, even brush work, the LOD quality will alter/change.  Take that into consideration for things at a far distance.

[AngelModder]

Well @@Oobah I hate to prove you wrong, but manual hint brushing is HIGHLY important in just about any map, while I do agree the engine does a great job for the most part, 60% of the time using hint allows YOU to decide how the portals will be split, not the engine which can work allot better as you will have a better understanding of what the player can see and not. The engine splits everything up into blocks (which you can adjust the size of), however some times 4 of them will all fall and line up at an area where really you don't need 4 areas to draw. and example of this would be if I were looking down the grand staircase. If I'm at A deck and stairing all the way down to F Deck I don't need the whole 100/92.5 ft of each floor drawing that it would do by these 4 groups meeting as they do. With a little brush work and manually placing hints, I set it up and drop it down to just 10 feet of details + the floors pieces only being drawn  on each floor as I look down. Hinting is HIGHLY important as it is the tool that allows you to dictate where portals will be, the same as setting them up down a curved brush hallway etc.
I know you're highly intutive with how the engine works, but I feel you're missing the bigger picture when it come's to hinting, its some thing I understand but just need some guidance on applying appropriately on this massive scale. Darth G was a living example of having huge areas and HIGHLY complex and detail things in them and yet his maps would have better FPS in his worst area's then SJC's BEST areas in his dreams...

This map as made successful use so far of the other techniques you have mentioned I'll hand you that, please understand I am not mocking nor knocking any thing you said, just I feel you are laying down already know general information, and Im looking for a bit more of a deeper guidance. Even you can admit this project is esspecially different than most, and ergo requires VERY special attention to ow it functions. I find that while it will do a vis compile with all structural brushes intended laid out, it takes a VERY long time, and in some areas like the promenade deck I was unsatisfied with how some thing's were working.
I did manage to work out some of the basics, but it wasn't as simple of a question as (to sound nooby) "How I map vis?" It was a ethical question of cut and up the brush count ergo slower compile but slightly better vis (still not to my satisfactory as my main question has still gone unanswered), vs leave them as one and just accept the vis draw on either side for the sake of a faster compile. Now I've went with screw the brush count, that doesn't matter if thing's are done right.The result is a 45% satisfactory so far. However as an above post show's theirs some odd problems I can't seem to put my finger on that even hinting is not fixing.

To better understand the map Ill lay this out, all doors in and out area area portalled, no windows will view in or out, simple glow maps and env's to replicate a semi sensation, it's an acceptable sacrifice for game play reasons. I understand that from an outside point of view and without the map physically infront of you in radiant to look at it may come across as a stupid practicality thing (this entire post), however I have been mapping now for over a decade, and this project has been ongoing for many year's, a trial and error, now it is as the point where it WILL succeed, but "I" and "IT" need help to get it to where it will be all around acceptable and not a catastrophic piece of eye candy like the beta or and SJC map. This project is my final for JKA, and means a LOT to me in many ways. I only request help out of a last resort, I dislike it even to be honest. However I am willing to admit I have reached a breaking point and weakness in my own knowledge. Applying basic techniques to vis is made highly complicated by how this ship has to be...

In many ways I would love to bring on another mapper who knows some of these applications better than I do, but can respect my work and the ship enough to listen to me and the needs of the project, look over it and honestly lend a hand in area's I am strained. However it seems that point fails to come clearly to some, and it seems most have a rather passive aggressive ideal when it come's to helping that rivals the costumer support at EA.

Regards and deep sincerity if this offends you.

AngelModder™

[Lazarus]

Hinting and portalling help, to a certain degree. I ll take a stance in the middle. While this map is build in a single box and has no areas to split easy, hinting is appropiate. It will require some hinting. but how much result you will get out of it is debatable, so @@Oobah is right to a certain point. But this makes you also right, @@AngelModder. So where is the golden line in the middle.

 

Now before you go all haywire on me. G knew indeed how to work with hinting. But to compare G's work with SJC goes a bit far. G was more of the scripting and less design, while SJC is more or less reversed. (G could indeed script everything. Name it, and he did it). His maps were always in high fps, because of his simple design. The sandcrawler was a good example from him. Sadly he never released it and it's probably gone with the wind.

 

Alright, that said, i ll peek at the file you tossed in my PM, but I am not a true wizzard on hinting either. I know my way arround it, but I am to wonder often too why the hint brush wont hide the portalling behind it. The fact remains that your outdoor will have to be rendered fully if you use certain brushes comes to mind here. It may even require slice up your ship to a certain points as well, if you want it to be optimal. Its not as easy as it sounds like when you do inside your ship, with simple areaportals and some hints in corners of 90 degrees.

 

 

 

 hint This shader is used to block vis around corners, it has to be placed so that it is overlapping 8 units with structural brushes in all directions. 

 

So why isn't it rendering propperly? check first your detail vs structural brushes as @@mrwonko said. From then start planning on how you should place them.

 

Check this out as well. http://tremmapping.pbworks.com/w/page/22453205/Understanding%20Vis%20and%20Hint%20Brushes

[Vulcan]

Here is the best tip I can give you:

Since every map is different, techniques are also applied different. If I were you I would make a few test maps and try out some techniques. Once you get the result you want you use that on the original map

[Oobah]

Well @@Oobah I hate to prove you wrong, but manual hint brushing is HIGHLY important in just about any map

 

Now before you go all haywire on me. G knew indeed how to work with hinting. But to compare G's work with SJC goes a bit far. G was more of the scripting and less design, while SJC is more or less reversed. (G could indeed script everything. Name it, and he did it). His maps were always in high fps, because of his simple design. The sandcrawler was a good example from him. Sadly he never released it and it's probably gone with the wind.

 

Wrong, manual hinting is not always needed or highly needed in any way, shape, or form.  The default calculations alone function just fine for the most part.  High FPS comes from cell sizes being to large, typically.  It's why even SJC's maps with huge custom made outside areas got FPS drops.  What about Szico Blue Ice or Atlantica exterior cell?  I get FPS drops and I'm on a quard core with 8 gigs of memory and a 680GTZ. 

 

This is an FPS game engine.  It's not an MMO/modern engine.  At a certain point it will simply dip the fps because it was not made for huge/large outside areas/cells.  Default portal calculations by Radiant might not be "perfect" but what the hell is in life anyway.  If you're running into issues manually hinting, chances are you're method/way is not any better than the one setup/done by the game engine itself.

 

Good solid mapping skills alone can either make or break your map, right from the get go.  Might take more work to map things out a bit more "cleanly" but it will save you long term headaches.

 

Even SP base install maps with large outside areas such as t2_trip, vjun1, etc all get fps drops at points due to the cell size being to far/large to fully render even with the fog they had in place.

 

There is better ways to render a more atmospheric surrounding cell backdrop than trying to shove it all in 1 cell.

 

No, it's not misc_skyportal either.

 

Of course you can manually hint and I would only recommend to do so if you understand how the portal system works to a point you can do it better.  Anyone can manually hint.  But if your mapping is fairly clean and solid, you really wont need to.  You can only squeeze so much optimization out of really any map/piece of work.  If you're getting any kind of fps drops or your rendering other parts of the map, that has more to do with your mapping capabilities and less with the portals generated.  Portals in the -vis stage are calculated after the initial bsp file stage.  Clean up your map and find a better way to produce the content.

 

Despite whatever fps drops some of the larger outdoor areas that Raven created with the base game, I still will give them credit because they still made some pretty nice looking content for use by players, despite whatever bugs/things they overlooked.  Have you seen some of the base maps in radiant?  Some of them are not even fully caulked/detail brushes, yet people still get pretty solid fps on some of the base ffa maps.  Even with there manual hinting, they didn't put it all over the map either.  They only manually hinted specific areas.

 

No reason to try and put every single cell into 1 large cell.  Not even Counter Strike: Source/Go mappers do that.

 

Hint is used for 2 reasons:

 

1) To create new portal splits to limit the Potential Viewable Set, reducing the amount of data that the video card has to draw.

 

2) To optimize the BSP-tree by merging or redistributing portals in a way that reduces the amount of useless portals.

 

You can think of portals as both planes and volumes. When splitting portals for PVS optimization, I think of them as planes - invisible lines that as soon as the player crosses over them, the next PVS loads or unloads. When merging them for BSP-tree optimiztion, I think of them as volumes. You are trying to merge adjacent volumes into a single concave volume. So in the 3rd hint brush example, I had 3 different volumes stacked on top of each other so I merged them into a single concave volume.

 

On detail brushes:

There's a misconception that only decorative brushes need to be converted to detail. Actually, you need to convert everything to detail that isn't directly used to create portals or a part of the hull. So even large architectural items like stairs, even entire floors may be removed if they're of no benefit to reducing the size of the PVS.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

First of all, try to convert as much of those small brushes to detail. This simplifies the portals the most. Then add a few hint brushes to limit the PVS in places like hallways between rooms and such. There are a bunch of hinting tutorials around that will teach you where to put these. Then look for portals that aren't doing anything with regards to the PVS and use hints to try to remove those.

 

Keep in mind that the blocksize also generates portals every 1024 game units along every axis. You can increase/decrease the size of this by adding the _blocksize worldspawn entity key/value pair. You can also set it to 0 to disable if you're comfortable to generate your own portals - though you should avoid this unless you really know what you're doing. When building your layout, you may want to build your floorplan keeping the blocks in mind.

 

When you have to many things as structural brushes the game calculates portals AROUND those things, detail them.  Anything that isn't mainly a wall/ceiling/floor.  So that means railings, stairs, elevator lifts, doors, ceiling lights, etc need detail brush.  Also if you have slanted walls, detail brush those to and setup a caulk layer behind it so it doesn't give you a compile error.  The game will try to calculate portals on curved surfaces also and they can also lead to issues of walls randomly vanishing IN the compile process.  I'm going to setup a potential guide on how to do background details so people no longer have to compile large exterior cells. 

 

Backdrop is for looks and the way I mapped it out, it has no drop on fps.

 

I can do big backdrops and not even have to put it all in a single cell.  Why?  Cause I researched on a method/way to do it.

 

 

[AngelModder]

A tut would be useful.

[AngelModder]

OK, so gonna try a few methods today based on your information, I'll post up if it helps and what I notice. Gonna try 3 thing's.

A: reducing the overall size ove the world around the ship, in a manor of peaking. It'll still have the same left right front and back view distance, but I think I can angle the top and bottom up and down in such a way to reduce the amount of cells being drawn at once. If I'm understanding Oobah correctly, it's not so much what's in those cells, as how many are being open to you at one time, too many and the game feels a drop even if they are empty space.

B: Really looking at what area's are going to be drawn no matter what and just changing the brushes that would be drawn in those areas to detail since I've broken the map up into several area portal areas, say like the grand staircase, then a door/portal into the forward bedroom corridors,  all the brushes in this area including the hallways and such can be detail, as it's all going to be drawn any way. The rooms (Most) will not have interior's so there just textured blocks, so each one as it's structural atm it splitting the bsp tree up, changing them over to detail will just make that section as it should a bunch of detail, with no need for structural brushes as it's a small enough and fps friendly area as it is.

C: Finishing out the interior plotting and seperating it as much as possible with area portals, within reasonable efforts to the original design. Doing this I only needed to place 2 doors in that were not in the original design. Originally there were curtains there, however I could not design a recreation of this I liked or that would work properly in such a manor to areaportal it. So Sadly C Deck forward and aft bedroom corridors will have doors.

I should mention that thus far the map has perfect FPS through out it, however tis whole discussion has been an effort to KEEP it that way but implementing further precautions.