BSP (Binary space partitioning)

Hi, All

1. BSP(Binary space partitioning) possible in unity3d ?
2. If yes How can it possible ?
3. How to implement in Unity3d ?

I have no idea on this topic, please help me

Thanks

 

It doesn't exist in unity, but you're free to code it yourself.

3.http://maven.smith.edu/~mcharley/bsp/createbsptree.html - code it in c# or preferbly a plugin in C++ if you really want to get down with speed.

Without being arrogant, I believe you do not know what you want or why you want BSP. Because if you did know, you would probably be able to do it yourself.

I suspect you have in your mind, that this will automatically speed up your project. But instead, you should make your world out of prefabs, and utilize the built-in umbra occlusion culling, which is what the majority of games tend to use these days, a form of open-ended culling.

BSP is really great if you want to get an answer to a problem, its not just about culling, its used for a lot of things, like seeking a specific piece of data out of a soup of data, perhaps this is why you wanted it?

Good luck in your search.

 

Thanks Hipocoder,

I m continue with racing game and I face FPS problem in my racing game.

I already manage 9000 vertex, lowpoly models, Occlution culling also But fps is 10-15 FPS in gameplay.

So i try to BSP in unity3d.

can any other idea to increase FPS ?

thanks

 

For a racing game, you don't needfully need or even want BSP, reason is that BSP is seriously limited in the geometry it can represent (it must always be convex among other things). Race tracks with objects that are meant to block a vew and alike could be technically impossible to use at all.

What you want is Occlusion Culling, be it in the form of M2H Culling or the recently released multithreaded culling lod system (sorry forgot its name, but you can find it on the showcase board) or in form of Unity Pro + iOS Pro + usage of Umbra PVS

A first start to get better performance though is what I mention below cause with the information you give it does not sound like BSP will gain you anything (BSP is the old way of doing what Occlusion Culling does now, back from days where the cpu was just too weak to handle more), I'm pretty confident that somehting else is totally burning your performance.

1. Don't use mesh colliders if not 100% required (lazyness for manual setup of many boxes is no reason for not doing it but a good reason to be punished with bad performance)
2. Don't have the whole environment as a single object but have them split by regions etc so stuff thats not in camera view is no longer rendered
3. Optimize the materials, dont use translucent and blending shaders unless you need them for sure (fillrate limits on 4th gen devices and ipad1)
4. Don't overdo it with particles
5. Don't use projectors unless the object that its cast onto is low detail and very local - anything thats hit by a projector will redraw for each projector hitting it
6. Don't use pixel lights unless you know how to optimize them (they combine problem 3 and 5)
7. Don't use OnGUI

 

thanks a lot Dremora

I will follow you instructions

thanks

 

Not using OnGUI compels to use 3d UI but that increases draw calls which again has to be taken care by static batching.

 

3D UI does not raise the drawcalls if done properly (see EZGUI).
While OnGUI will definitely raise the drawcalls as every GUI.XXX call ends as an own Graphics.DrawMeshXXX call internally and those can not batch at all, so each GUI.XX adds an own drawcall.
But the real problem is not just the drawcalls but the fact that OnGUI is called up to a few dozen times per frame and it has a not insignificant overhead, which in the end causes a lot of cpu time being eaten and garbage being created.

Since Unity 3 the regular iOS optimization guide in the manual warns from using it at least

 

BSP is the worst choice for a driving game because the strengths of BSP is that it can hide geometry in indoor levels (well more accurately, if built right, retrieve what you can see in a fast way). BSP trees have zero value for a driving game.

What will speed ios is (you'll have to search forums but these are good things to search for):

1. reduce draw calls
2. use mobile shaders only
3. don't use transparency and lots of separate objects

 

+1 for dreamora and hippocoder
I agree, reduce draw calls, use mobile shaders, don't use transparency, use as few particles as possible.
Oh and check your texture resolution (and compression) and if it is power of 2.

 

But if transparent textures are not advisable, then how about text-meshes (instead of graphic images of texts), because text-meshes will also, to some extent, incorporate transparency for anti-aliasing for instance.

 

Transparency is fine, if you're not covering the entire screen with it multiple times (overdraw) - using the mobile / particles / alpha shader is in actual fact pretty fast so long as its drawing over solid stuff. If you start doing alpha over alpha, thats when the mobile platform tends to fall over and die.

Like particles from your skidmarks or exaust, or layers of glass on buildings etc, I'm sure you get the idea. The best way to do text on ios is still to just use one mesh, with one quad per letter uv mapped from an atlas. Try out prime31's gui for a free version of that.

 

I'm glad I wandered into this thread. Had no idea OnGUI() had such horrible performance. Is this really the case though? I thought OnGUI was called ~2 times per frame. I can't say as I know how many draw calls it makes though. I've not had an overly in depth game so never hurt from using OnGUI before, but I'm working on an incredibly in depth game atm, so it could definitely make a difference.

 

Thank you all of you.
Will have to try out and re-sculpt some things

 

Using OnGUI on iOS should be banned. In fact, I wouldn't mind if Apple started rejecting apps that used OnGUI Unity GUI has lackluster responsiveness, doesn't work with multi touch, was not designed for touch, etc, etc, etc. Every time I play a game and see Unity GUI used in it I die a little bit inside. Please seek an alternative and do not ever ship with Unity GUI.

 

Is it only in mobile platforms it gets such bad response, or all platforms? Also, what would be a good free alternative?

Also, if you don't mind, could you explain exactly how it works and why it's so bad as compared to other solutions?

 

@Spectre, mobile is the most noticeable. I personally wouldn't ship mobile or desktop app that uses it though. I can't tell you how it works (only Unity knows that) but I can tell you that it doesn't work well and the performance is terrible. Lets just say there is a really good reason Brady (the creator of EZ-GUI) is holding a check this big. People are willing to spend $199 for a replacement.

If you are looking for free solutions, there is the original SpriteManager which still works just fine and we released the open source UIToolkit for free as well. We released it quite literally because there were some really good Unity games that were using Unity GUI and it totally ruined the experience and made them lack polish and annoying to play.

 

Prime's gui is not only free, but it does every kind of gui thing, like knobs, sliders, buttons, animated sprites, fast mesh text etc...

 

I'll try those out and see how they look, thanks. It's kind of sad really, cause I had gotten pretty good using Unity's GUI system for everything. Looks like I'll have to learn a new system.

 

What is exactly UIToolkit? If I want to make 3d UI for ipad game?

 

Thanks for the man who effectivly is searching for a BSP tree c# implementation and fall down to this thread :/

 

Hi all. Haven't read the whole thread yet, but thank you to my predecessors for doing the precursor research on this algorithm being implemented in Unity. I am hoping to use some sort of procedural level generation algorithm, possibly not this one but would need to study this one I think the get a good idea of the background, for a maze-like game, 2D top-down. So, to put it bluntly, I would be using this for its intended purpose--random level design. Although, apparently from some of the posts I read here it can be used for other purposes? Neat?

 

I think the link might be dead. It doesn't load for me.

 

Bump: Try http://www.rombdn.com/blog/2018/01/12/random-dungeon-bsp-unity/

 

Could a mod relocate this thread to the appropriate location please?

 

I know I'm bumping a dead thread, but for what its worth, I feel that building some levels with a BSP tree backbone has some advantages that make a bunch of downstream tasks a lot simpler.

• What regions of the map are solid vs. open air is always well defined. Therefore, you can guarantee that objects cannot fall out of the map or enter large spaces intended to be solid, unlike with surface-based collision.
• If most of your level (at least its coarse geometry) is blocked out with BSP, occlusion culling comes more or less for free.
• By marking what partitions are accessible to the player (like those with walkable floors, for example), you can cull objects and surfaces that will never be visible, exclude static surfaces from lightmapping, etc.
• The partition boundaries provide a useful way to group static meshes for combining into a single static mesh (static batching). You can use visibility data from player-accessible partitions and cluster static meshes based on what partitions their bounding boxes overlap with, and how likely they are to be visible at the same time.
• It provides clean coarse geometry for other baking tasks, like navmesh generation, light probe and cubemap placement, reverb zones and other sound baking, etc.

Basically, it provides a useful way to organize the layout of your map for situations where you need to assess visibility, proximity, occupancy, solidity, or map topology (what partitions have shared faces). Without it, a lot of the downstream stuff I mentioned has a lot of error-prone work ahead of it to make sense of what is otherwise triangle soup, and cannot make as many assumptions to take computational shortcuts.

It may even be possible to encode a simple BSP into a texture and then raycast into it on the GPU, to get simple but fast raytracing for reflections, a bit like how box-projected cubemaps work.