• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
xynapse

Indoor rendering

45 posts in this topic

Guys,

i can't find any good information on what to use when it comes to render indoor areas only.




We all know BSP but do we use it those days ?


BSP ? Portals ? Octrees ? Quadtrees ? BVH?

What should i pick if i think of an engine rendering only indoor areas ?





There are of course tons about BSP (and that quake old school stuff around) - but i can't imagine that in this century..




I need to achieve a flexible solution so that people doing level editing just export the mesh from the 3DS MAX and...

and yeah, what is the tech i should use to render efficiently indoor levels?




Thanks for any input into this.
0

Share this post


Link to post
Share on other sites
Unless you just want to batch your entire level then yes, that is still the preferred way to do it.
0

Share this post


Link to post
Share on other sites
Well...

I've been recently working with high-performance BVHs in my scene management subsystem in my engine and actually it works a bit better than BSP (because it can dynamically handle fully dynamic environment). View frustum culling is at very low price (giving a bit of boost to performance), but Occlusion culling is not giving that much boost (depends on scene) - it's price is really a lot higher than frustum culling test.

As far as I can tell - try BVHs, you won't get as good results as with BSPs (in terms of speed), but you'll be able to handle scene fully dynamically (BVHs can be built/rebuilt in realtime quite quickly).

1

Share this post


Link to post
Share on other sites
Portals are [url="http://geck.bethsoft.com/index.php/Occlusion_Culling"]still used[/url] and BSPs are [url="http://developer.valvesoftware.com/wiki/Source_BSP_File_Format"]still used[/url] too.
2

Share this post


Link to post
Share on other sites
I decided to go on with this thread a little bit and explain you guys what is the engine characteristics in terms of choosing the right algorithm from those listed above.

I Found your answers very helpful and just need to pick the right option here, but before that i just want to be fair with you and let you know the game specs - as i know that deciding about something without even looking at the presentation is a hard stuff to do.




[b]From the game specs:[/b]

i read that the requirement is to implement the static objects mainly, so we'll have to manage animations more often than objects to traverse between rooms.

I see a 'level' is to be made max from 3 rooms which would be basically separated by doors that are to be opened when 'something is done' - so a typical approach,

you're stuck in a room until you find out the clue how to get out of there ( find a key somewhere and use it on the doors ).




[b]Lights [/b]- max 2 lights per room which isn't that much




[b]Shadow casters[/b] - 1 main shadow caster (omni) + eventual spot light shadows from player's lamp




Here's a drop from the already-being-built level area - it might explain more and help choosing the right algorithm for this game:






[img]http://extraordinaire.pl/gd/indoor2.jpg[/img]




that is all they ask for.




As far as i go with the docs i find it more simple,

a player walking around, finding out clues in a one room, 3 clues found in 1 room lead him to the doors that can be opened and player moves to another room -

but can always come back to the first, and second one - so as i said 3 rooms within a level is what they are talking about.

To make it scalable - let's say they need 10 rooms ( in case they'll change the plan ) .




I would like to pick the most optimal level management option for this game and focus on 'loosing' fps for special effects and lighting instead of thinking when it's too late 'why did i choose that?'.







So what do you think now guys ?
0

Share this post


Link to post
Share on other sites
will doors between rooms close again?

if you make it so that doors close themselves you have an automatic solution... if all doors to a room are closed and the player isn't in it... then don't render the room.
so even unlocked doors still close themselves after a short time or once the player moves away from them by a certain distance or something.

using this approach you could have looooads of rooms ;)
0

Share this post


Link to post
Share on other sites
[quote name='bwhiting' timestamp='1319708351' post='4877505']
will doors between rooms close again?

if you make it so that doors close themselves you have an automatic solution... if all doors to a room are closed and the player isn't in it... then don't render the room.
so even unlocked doors still close themselves after a short time or once the player moves away from them by a certain distance or something.

using this approach you could have looooads of rooms ;)
[/quote]




Unfortunately nope, when doors are opened they stay opened and you see other room/s, you can of course close them.

My manager says that there might be a situation that doors can be auto-closed when a 'trigger' happens, but it is not a common thing - so we need to build a generic indoor engine here.




That door's system leads me to think i need to have Portals solution in place, but still want to confront that with your suggestions..







0

Share this post


Link to post
Share on other sites
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 [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]
0

Share this post


Link to post
Share on other sites
[quote name='bwhiting' timestamp='1319711175' post='4877511']
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 [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]
[/quote]
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 ;)






0

Share this post


Link to post
Share on other sites
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.




0

Share this post


Link to post
Share on other sites
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 ...?
0

Share this post


Link to post
Share on other sites
[size=2]Actually, with today's hardware, does traversing the BSP tree make sense? If you have portals + PVS, then you've solved most of the visibility issues.

Based on the player's position, for each set of polygons that's visible, just draw the whole set. All these buffers are static VBOs, stored probably on the graphics card. The graphics card will just claw through the polygons faster than you can traverse the BSP tree to figure out exactly what is visible. Note, I'm assuming a desktop system with a non-ancient card; if this is for a mobile device, maybe BSP is faster.

I'm using a dead-simple system in my project: Draw whats in the player's current room, recurse into rooms who's door is open and the door is in the frustum. While recursing, 'shrink' the frustum to fit the door. [/size]
0

Share this post


Link to post
Share on other sites
A mixed hybrid of CPU and GPU occlusion checks. Build a model of the world, a bit like physics, but occlusion world that is contained within every entity in game. You might want to google how [url="http://en.wikipedia.org/wiki/Umbra_Software"]Umbra[/url] does stuff.
0

Share this post


Link to post
Share on other sites
[quote name='xynapse' timestamp='1319824133' post='4877921']
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.[/quote]

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




0

Share this post


Link to post
Share on other sites
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 )




[img]http://extraordinaire.pl/gd/indoor3.jpg[/img]




[img]http://extraordinaire.pl/gd/indoor4.jpg[/img]







Eventual portal positions

[img]http://extraordinaire.pl/gd/indoor5.jpg[/img]




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 ?



















0

Share this post


Link to post
Share on other sites
Surely this is very simple logic...? If you give each sector an id - I'm sure all your static objects have an id - each portal has two ids, one links to one sector and the other links to the other. Does it need to be any more complicated than that?
0

Share this post


Link to post
Share on other sites
[quote]Surely this is very simple logic...? If you give each sector an id - I'm sure all your static objects have an id - each portal has two ids, one links to one sector and the other links to the other. Does it need to be any more complicated than that? [/quote]

Yeah thats all you really need. In my system, my portals are single-directional. Each sector has a list of portals, and each portal has a target. So to connect room A to room B, room A has a portal to B and room B has a portal to A. This lets me do weird things like have a 1-way doorway; like a teleporter or something.

Also, my portal implementation is very simplistic at the moment. I considered using fancier occlusion tests, but I'm getting good results with a bunch of cheats. For instance, my culling 'frustum' is really just a cone.
0

Share this post


Link to post
Share on other sites
As promissed i'm back with the results.

We went the Portal way, and thus a level designer places portals manually as faces, describing each portals visibility in terms of a sector it sees.

Each room is made of separate object, so when portal is placed we define which object it sees.




[img]http://extraordinaire.pl/gd/indoor6.jpg[/img]







The engine itself, checks for portal that is seen in the frustum (by testing portals AABB and the frustum) and generates a list of sectors visible for the camera.

[img]http://extraordinaire.pl/gd/indoor7.jpg[/img]




I think this would satisfy the requirements for this project.

Now i need to 'cut' the frustum to the portal size when iterating through.

Will of course come back after this gets implemented.


1

Share this post


Link to post
Share on other sites
was working earlier today, I guess the server is just down.

@xynapse

there are two other alternatives to cutting, one simple is to just adjust the 4 frustum planes to 'touch' the new portal, this keeps the checking simple and the results are as good as with cutting.

and alternative is to create a portal 'stack', where you just keep adding frustum planes based on the new portals, the nice part about that is that you can nicely vectorize it (e.g. SSE) and you can add 'anti portals' by just inverting the frustum planes, e.g. when there is a door etc.

0

Share this post


Link to post
Share on other sites
Sorry the server was in maintenance yesterday.

Now, as far as i can tell, the portal approach is a very straight forward and easy going technique.




Here is the portal class definition, i know some people might find it useful when looking on the forum so it might help them a bit




[code]

class C3DPortal
{

public:
C3DPortal();
~C3DPortal();


bool Parse(const std::string& strPVSDefinition);

void SetAABB(const CBoundingBox& rAABB);
CBoundingBox * GetAABB();

void RenderAABB();

private:
CBoundingBox m_AABB;
bool m_bActive;
std::string m_strPVSDefinition;
std::vector<int> m_iPVS;
};

[/code]
The [b]Parse[/b] method is used to setup the portal, the string that it takes comes directly from 3ds max object properties window as per below:




[img]http://extraordinaire.pl/gd/indoor8.jpg[/img]

So when i import the mesh data i read in the portal definition as a string and pass it to new C3DPortal instance for it to perform internal setup.

This approach allows me to do future Portal expansions/customizations for level designers based on the parsing facility.




A vector of [b]int's[/b] holds the [b]PVS[/b] ( a list of id's of rooms the portal "sees" ).



This is kind of a base Portal - nothing else is now needed for it to work.

As i am now approaching to do the vis tests based on portals i came up to an idea that it would be good to calculate/store the 'portal frustum' when the Portal is being created.


We can do that as we have it's AABB.


So later on when checking for Portal visibility instead of cutting frustum per frame i get that data precalculated at portal creation phase. What do you think guys?




@ Krypt0n - i liked the second idea, can i ask you to help out with the details of this approach?




Thanks guys for keeping this post going.




Be back with an update later this day.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0