While I'm not sure what position your in with regards to moulding how this goes but I often find if I approach the powers that be with some cold hard facts supporting an idea they often respond the right way.

i.e. propose a few solutions one of them being, doors that close automatically and with this small alteration/addition they get faster build time, a much more simple to update system, highly scalable with no extra effort for designers etc...

when you lay it out like that it will make your solution much more tempting, all those benefits and just from coding in some doors mechanics (which aren't that uncommon)

but this might not be possible for you as I don't know your full brief or what your client and managers are like.

good luck

While I'm not sure what position your in with regards to moulding how this goes but I often find if I approach the powers that be with some cold hard facts supporting an idea they often respond the right way.

i.e. propose a few solutions one of them being, doors that close automatically and with this small alteration/addition they get faster build time, a much more simple to update system, highly scalable with no extra effort for designers etc...

when you lay it out like that it will make your solution much more tempting, all those benefits and just from coding in some doors mechanics (which aren't that uncommon)

but this might not be possible for you as I don't know your full brief or what your client and managers are like.

good luck

I would really love to have a chance to propose new approaches in the area but as you probably know - i meet the escalation path, and people above stand hard as rock without even trying to hear what are some 'new better solutions'. So it always comes back with : "Client requirements are more important than our proposals".


And at the end of the day it's all about: meetings, reports and feedbacks.

Argh, you probably know all of that ;)

if the basic level geometry is really made from boxes, you could calculate the bounding box for them, then calculate a PVS (as you said they are static).

all the other objects can be sorted into those bounding boxes, it's also easy to check where the player is.

Bad news are, that they client pointed out something about BSP during the meeting, and it seems we will have to go that way..

BSP, PORTAL + PVS - is what will satisfy them.

Now as it turned out into something i wouldn't expect, seems like right now i should be looking for a good class / info of how to convert a level that is a mesh to a working BSP +PORTALS+PVS solution..


So the scheme would now look like:




3ds max level -> goes via exporter to the engine that loads this model and 'does' bsp + portals + pvs on it..



Damn.. Anyone can point me to something worth studying, or maybe you guys already have something working so i could have a look to find myself in this and understand how it really works ...?

Bad news are, that they client pointed out something about BSP during the meeting, and it seems we will have to go that way..

BSP, PORTAL + PVS - is what will satisfy them.

sounds like not an engineering, but a communication problem, as you shall propose the best solution for the clients ;)


the world of engineers developed a solution for that called 'overpriced consultant', he will ask your team what you think is best, will present that to your clients next to his bill and they'll tell you to do as he said.

</joking>

I suggest, you to first check out some open source bsp compiler, maybe one of their license fits you and you'll save tons of work.( you don't have to deliver the bsp compiler with your software, I guess).

There are quite some paper about automatic portal placement in bsp trees, I think last time I was reading bout it was in http://www.amazon.com/3D-Games-Real-Time-Rendering-Technology/dp/0201619210

Success, it is up to me now to decide what to use to get this game going, so i have 5 days ( till Friday ) to figure out finally what to choose.

Luckily we can forget about that BSP scary thing - this method always looked for me like overcomplicated...




I liked DracoLacertae's idea, have a bunch of objects as the map - each representing separate room ( sector ) and additional place portals within editor for later culling.

Theoretically a single VBO/IBO or just VAO per sector can do the thing when it comes to render the room with a single call.







Now when it comes to design - this is something i would like to ask you, as you guys have an experience and your engines are already up and running.

Also i know that a good design leads to better development and there is no need to do any rollbacks later on - thus i will try to go into details of: "How to generate the sectors and manipulate them".




I always say it's better to see something and speak about it than to spend a time figuring out what the heck are we talking about so,

Let's have a look at the first level ( this is the official level one map mesh/scheme )

















Eventual portal positions






Now as level designers will place portals manually ( i think there is nothing wrong with doing it 'by hand' what do you think?) - and i will probably export them as a separate list of faces -

how do i know which portal leads to which sector ? So when testing visibility i will know that

Portal[x]->Leads To Sector Y

I am kinda worried when thinking that this information would have to be provided 'by hand' somewhere and would love to have this a bit confronted with what you do.




Knowing that a level is made of objects - each being a separate sector, how do i handle data within a Portal face, that informs what sector that Portal leads me to ?