Krohm

I stated that there were some opensource applications that would do all of the collision for him, I suppose I got into the details too much and that went unnoticed. Some people are building an engine for a portfolio, in which case I don't see how plugging in some opensource middleware shows that you understand how engines work at their core.

Yes, I understand your position, but I think it was worth stressing this more. Maybe it's just me but I think the message completely got lost.
Yes, I understand this position very well. I still think it's not worth spending 6+ months on physics... because after 2 months, one will still be scratching the surface, I can tell for experience, and there's at least another few dudes around here that will agree.
Problem with physics is: unless you use it in creative ways, it's assumed to be there. Let's do the city-major comparison: who do you think will get more preference?

• The mayor which spent $ on fixing and maintaining the sewers, ensuring no one gets flooded.
• The mayor which spent $ on a new stadium.

Although many companies claim to "have interest in acquiring complete know-how in developing internal technologies to leverage our customer's potential" the truth I had to learn in the hard way is they don't even have the means to evaluate this property. Therefore, the more you bring them, the better.

You state that having multiple BV's will be hard for the compiler to optimize, could you please give more detail about this? I'm assuming you are thinking of a game in c++, but even for my javascript engine im curious.

Yes, it's C++ related. The idea is that stronger assumptions give faster code. For JS, all bets are off as this is implementation dependent at best but in case of JS in Unity, they claim not messing up with type can produce faster code. I look forward to your JS-based project!

If you are trying to make a fps where picking has to be 100% accurate then OBB's may not be enough.

Probably need to elaborate on this. A thing is the broadphase, a thing is the narrowphase. AABB based broadphase has proven to be good enough. The goal of the broadphase is to be a fast rejection test, and AABB has demonstrated to be the fastest test around.
The narrowphase later takes all the potential collisions and resolves them in detail by computing "collision distances", this data is also used to improve stability as far as I've understood. The narrowphase uses solid's effective "shape". Most of the time, this is already a rough approximation. Personally I think convex hulls are the real deal, but Bullet also allows to resolve narrowphase collisions using generic meshes. Their performance seems to be really bad but that's what we get for accurate per-triangle collision.

There's nothing really wrong about what you're doing as far as I know, it's just pre-2003 collision detection, it worked well and can still work; I am surprised you pulled this out in 2 months but if it works for you, that's just great.

Perhaps it is just me, but I think this thread has gone so wrong it's hard to believe.

I have a little terrain (maybe like 100 x 100 meters) with some trees, houses, rocks etc. The player moves around this little map and I need collistion detection against the objects and picking ... what could be a good and simple (!) approach to solve my collision detection/picking?

Simplest solution: use a collision detection library. Such as Bullet or PhysX (I'm currently using the former).
In particular, note that Bullet uses allows different kinds of broadphase tests, one of those is an AABB tree. None seem to use OBB. AABB rejection tests, simply put, is so fast it greatly compensates the loss of precision. This behavior emerged in various other papers.

Bullet can do the CD&R for you in a large array of cases. In principle, collision detection between static and dynamic objects become essentially transparent to the application. Kinematic objects however are not transparent by definition. You will need to write the glue and this glue will be application-dependent.

Picking is pretty much supported in Bullet by using ray casting and it's both fairly flexible and accurate. I haven't looked at the performance of this functionality yet, but from a 10,000ft view, it seems promising. PhysX also supports raycasting AFAIK.

In both cases you'll need to go a bit through the hoops to link bullet collision objects to your gameplay-specific entities. In some pathological cases, this can be a bit troublesome (but it's probably an unfortunate byproduct of my current design).

Some objects are rotated (for example some houses) and for these objects an AABB would be pretty bad.

In this case you would fetch the physics API with a different Collision shape. No need to mess up with different representation. In case of Bullet, you could eventually encode this as an opaque blob (although I don't suggest to do that). You have prenty of collision shapes available including heighfield and convex hull. Want to be really accurate? Gimpact trimeshes will do.

What do you think about this: All my scene objects return a polymorphic bounding volume object, which can be a sphere or AABB or OBB. For most of the objects I return an AABB and for the rotated houses I return an OBB. Good/bad idea?

Probably bad in most naive implementations. Bullet does this under the hood but in some seriously elaborated way - AFAIK it's basically doing all the "casts" in advance to select an algorithm for accurate collision, then dispatch. Broadpase is probably AABB or OBB at best.

DarkBouncer, what you write about this is correct in line of principle - this info must be stored somewhere - but devil is in the details and what you seem to suggest has the potential to make this performance critical path more difficult to optimize by the compiler. Therefore, I'd avoid it.

I also thought about a 2 pass system: All objects return an AABB and only if the player partially overlaps with the AABB, I make an OBB test.

Nonsense. If the rough collision test matches, I don't think it's worth doing another fast-rejection test which 1) is not so fast 2) it's going to likely fail. Do yourself a favour: optimize your life instead, get the job done and use a physics API!

DarkBouncer, what you said is not standard design. Standard design is to perform a fast rejection test, if that fails, work it out in detail, perhaps using some kind of data structure to accelerate the whole thing. Stacking multiple gross-grained tests is not standard at best. If the nested test would be a convex hull I could understand, but sphere to box? It's like multiplying two random numbers together and claim better randomness, or encrypting data twice using two algorithms and claim the result is more hacker-resistant.

Do you think its ok to just linearly iterate over all my scene objects and just test every object with the player? (I guess I have around 50 objects)

I suppose it could be doable for 50 objects (I guess you have a iSomething processor) but don't expect this to last long.

And who should be responsible for building the BVH? Currently I am only telling the scene manager: place this tree at this position, this stone here and so on. I guess computing a good BVH automatically by the engine is not that trivial, is it?

The physics API. And trust me, it will dispatch fairly better than you.

If you want a well done collision detection system with picking you are looking at having to implement the following...
Don't get discouraged though, it's all doable, just trying to share my experiences to give you some insight into what lies ahead.

You are sadistic. Look, I really understand you want to share the pain but seriously, I don't see any reason to not use a physics API such as Bullet. If I look back I see myself scratching my head to the brains working on CD&R. Why didn't I go for Bullet a couple of years ago? Why did I do that to myself? Why do you want to do this to someone other?

Another question: Would you recommend using the same structures for collision/detection and culling? For example is it a good idea to make collision/detection AND culling just based on bounding volumes on the objects. Or is it better to use bounding volumes for collision/picking and some other structure (cells, quadtree) for culling?

You can use the same structure, but it must be built differently (at best) as the granularity involved need to be much different. Consider that even if you have 1k unique vertices per leaf, this is still very little for anything that is at least GeForce 4 (not 400 series, 4). Regardless of the data structure you use, unless you're doing AAA+ it will start to be pretty much the same thing as a linear scan once the leafs hold thousands, if not tens of thousands primitives.

If you use a physics API then I suggest to just build your system independently, the accuracy of physics API is just way overkill for culling on modern hardware.

I don't know how to properly setup fullscreen app on my monitor. If it maters i have Samsung synmaster 2243sn 21.5" an my "native" resolution on desktop is 1920x1080 witch is, i gues is a wide screen monitor
For example if i set 1280x720 to be my resolution i have black bars/borders on top & bottom part of screen show.
But if i set (for example) 800x600 then it does not have that black bars and its  shown on whole screen, but then models rendered is streched even if i provided correct aspect for my camera.

Unfortunately, LCD monitors can be a bit of a mess. They will always try to figure out whatever it is better to stretch & deform or to leave black bars. It looks like yours likes to keep 1:1 mapping for resolutions matching the ratio, but has absolutely no respect for non-matching ratio.

As far as I know, you cannot do much in D3D9, nor GL, nor D3D10, nor D3D11. Perhaps with some system call in Vista or 7. I don't recall one in XP.

Check out your driver settings (nvidia allows you to set the behavior). You might also want to play a bit with your monitor... using the hardware buttons and those crappy OSD menus, maybe there's a setting.

Nonetheless, your best bet is to just use the current resolution.

As for the T&L cache, if I remember right from my architecture class, when it first gets a miss on vertex 0, it will pull in (I think T&L cache's store 8 vertices?) 0-7 into the cache.

I couldn't observe that effect. I would say it is implementation-dependent at best. I suggest you to not even think about this. It's simply premature optimization.

Optimizing for T&L cache is just a matter of spatial locality. Last time I made benchmarks (GeForce 6) we were talking about at least 16 unique vertices. This is more than enough for terrain and I expect the number to be even greater on nowaday's HW. It is therefore fairly easy to make strip runs so most vertices are transformed once.

Again, on GeForce 6, strips used to be about 3% faster. But i'd take this with some salt as the value is on the same magnetude as noise.

Personally I would go for triangles and be done with it. Strip-jumping/primitive restart is just not worth the effort IMHO.

DICE presented a method of doing decals using GS and stream out some time ago. I never had the chance to play with it though.
So far, my decals were done in the old way: coplanar polygons with z bias.

If you use the search button perhaps you'll find multiple discussions about the voxel->polygon mesh conversion being done at preprocessing.

I cannot tell you any personal success story, but I can warn you by telling a story of failure. ROAM. Wasted effort. ROAM for generic meshes? Don't even get me started. Seriously. The scars still hurt.

Want to do LOD? Ok, either chunk or clipmaps (google "hoppe terrain clipmaps"). Both can scale to very large terrains given appropriate management. I'm actually more inclined to chuncking.

Extended view distance introduces a few extra problems however. Logarithmic Z is pretty awesome, but I don't know if it is doable for AAA games. Dual frusta techniques have in my opinion a few issues which perhaps can be worked out. In the past, I was planning to make an hybrid system using "far portals" and some render-texture but I didn't had the time to try it.

At the moment I'm handling it inside the WM_KEYDOWN WM_CHAR and WM_KEYUP messages.

As user of a non-standard keyboard layout, I want to thank you for realizing the important difference between button presses and characters generated. I've been stressing this for a few times, thanks god someone does that right!

Is this correct or should I use something like the directx input that keep an array with the current buttons state? I mean, should I call a function that updates this array inside the main loop or should I continue with my actual method?

DirectInput has been deprecated for a while right now. Don't even think about it. It seems it's emulated on top of KEYUP/DOWN and CHAR. Do not use it for keyboard management, nor mouse.

You really have no chance than storing everything in an array of some sort for later processing. In general, do not make "complex" calls from WndProc, where "complex" means "could throw an exception". Whoops. That means you cannot allocate memory using new! Unfortunately, WndProc is defined in C terms. That means C++ features are not guaranteed to work properly, especially when dealing with exceptions. Now, it might eventually happen to work: i don't know. And I don't even want to figure out. This is a C func, and must behave as such.

You absolutely want to have a better separation between input and processing. Processing "actions" is typically high gameplay-level behavior, having separation is heavily recommended. At a certain point, you'll find yourself in the future, with your system having no knowledge at all about those "actions". I think this is good.

As far as I recall, it should be automatic for fullscreen apps in D3D9. SLI introduces some issues with synchronizing contents across the boards which can be tracked using appropriate profilers.
I'm still not quite sure SLI makes any sense for gaming but I'm fairly sure it makes no sense at all for learning. Even a low-end card will provide more than enough perf for you for the next years.

What's the point with this.

I mean, if you post on youtube, 50% of the comments will be like "this is crap", "<game of the month> looks way better" etc. Those people are very lucky. Or perhaps they're spending $$ on PR. Look at the mess going on. How can people even think this is real? Don't they see the painful patterns? That's the only thing I don't understand.

Next time I'll have a work meeting I guess I'll promise infinite possibilities. If talking shit is going to get me the money, I'll sure have a try!

It's time for unlimited detail yet again!
I love the technology. By sure, I have a lot to learn from those guys because 1 year later they're still running the marketing pretty well!
We still don't have any measure of complexity, nor knowledge of hardware requirements. They claim they can make it run at 20 fps on software... who does even care. With this shading complexity, I don't see much of a problem. They improved it only slightly WRT the old video. We still know nothing about the workflow, nor the amount of preprocessing. What have we got?

Multiple different meshes! Ok, the LODding is admittedly awesome. Point taken. They are instanced a lot, a lot, a lot, a lot, a lot, a lot, a lot. Especially apparent for grass.
Improved shading capability: they are beating me hands down!
?

Anyway, I talked to a man in the GIS sector who claimed to be able to mangle a 5 Billion point dataset "with minor sweat"... I suppose he could say something about working with point-cloud representation as they scan whole valleys as daily routine!

v0 = C + U * hu + V * hv + W * hw
v1 = C + U * hu + V * hv - W * hw
v2 = C + U * hu - V * hv + W * hw
v3 = C + U * hu - V * hv - W * hw
v4 = C - U * hu + V * hv + W * hw
v5 = C - U * hu + V * hv - W * hw
v6 = C - U * hu - V * hv + W * hw
v7 = C - U * hu - V * hv - W * hw

Notice the +- pattern.

Assuming U,V,W unit length.

But seriously, this is basic vector math. Try it out on a piece of paper. If you cannot figure it out then you must absolutely check out your basics again.

What's the alternative? I considered making a component base class and putting a list of these into entity - so if it has only a PhysicsComponent and an AnimationComponent, the list would have 2 elements. This however raises the possibility of an object having more than one component of a type; isn't this bad?

Only if the underlying semantics are meant to be unique. Which is possibly a good reason for which Unity goes that way.

Example of "good" multi-component: adding multiple "spurts of blood" to a model which was hit - attach multiple ParticleEmitters to an entity.
Example of "bad": adding a 2nd "transform" sub-component. What transform to use?

Sorry, I'm not sure what's meant by "the generic list approach", or components "living by themselves"... Please bear with me - I'm pretty slow with understanding this subject. Perhaps it would help if I just try to shove together an entity system now and see what issues need addressing, then I'll be able to relate to what you've said.

Those issues are were touched (although not deeply investigated) in the other discussion which I strongly suggest to read as it was very helpful to me.
Using the above example: suppose an entity got a particle emitter. Those sub-components don't actually need to 'tick'. They will just evolve and change state by themselves because somebody (the system managing them) know they exist. Simply because they exist. You cannot update them as as nobody guarantees (in a pure component model) entity X will get only sub-components it knows about. At best, you could 'tick' them using a generic interface.
For example, say we are running in a "visual debug mode" so each "trigger entity" actually gets a "model" sub-component attached to it... or in editor mode, a sound emitter gets a speaker icon attached which will render as a billboard.

Well, I was thinking the position of a mounted knight will definitely depend on the position of his horse; considering the two are both individual entities, how do I relate them without propagating their positions?

I asked the same thing. It's not a question of doing what, pure terminology. See his very clear explanation.

I meant the type of entity is inferred from which components it has. Is this good practice?

It is not relevant for a component model (and I wonder if this is possible in the first place). The type of an entity and its behavior emerges naturally from the interactions between their internal sub-components. Perhaps you want to use a standard (perhaps inheritance-oriented) entity model?

Actually, there's another important gap in my understanding... I'm not even sure how components should communicate between themselves. Let's say the AI or Input component wants to change the component holding the entity's position - how would that be done?

I'm working on this right now (hence my interest in this discussion) to connect rigid body dynamics to mesh drawing. My solution for the time being is the following (but it doesn't work with dynamic composition for the time being).
A RigidBody and a Mesh are put in an "entity". The same piece of code doing that has knowledge of those two types. My RigidBody has the ability to notify another object of position change using an interface (TransformListener). An object of a class implementing TransformListener is used to explicitly connect RigidBody to Mesh.

Problem is the system was routinely abused as I see it.
Some pieces of tech discussed here can work in quite counter-intuitive ways. People not understanding will not even question their knowledge... will just thumb down.
It is way harder to get thumbs up. Even if the solution is there, I've often seen no thumbs up, no thank you, nothing. They just go away. I think the up/down system has demonstrated to not work.
Positive-only feedback seems to keep all the advantages, yet I don't see any of the cons. I like this.

I'd suggest to put more emphasis on one or the another depending on the recruiter. I have the feeling (I cannot demonstrate this) I've missed an interesting position because I switched GL->D3D some time ago... because you know, D3D is just for games. How many things are wrong in this statement?

Anyway, don't even think about learning both at the same time. They will make a huge mess. I'd suggest starting with D3D10/11 if you can, build something and then try to port.