The 3DGS collision system is AWFUL.

Seriously. Why was support for AABBs dropped? I'm trying to iron out the collision bugs in G.R.U.N.T.S, but they are unstoppable. Ellipsoids are incredibly unpredictable. They get stuck so easily that you have to wall up your entire level with invisible borders, or the next thing you know, your player entity is trying to climb into that mouse hole!

The Quake engines still use the AABB system for a reason. It's reliable, easy to manage, and accurate. You can't get your stomach caught in little holes in the wall because your BBox sticks out a little in the middle, and size adjustments can be made on the fly to easily accomodate features like smoothly walking up and down stairs and ramps.

So why has the AABB system been replaced with this repulsive OBB system?!

I hate it, too. I spent so much time on avoiding ellipsoid collisions and trying to (re)create bounding box movement, esp. for platformers.

EDIT: The rest of the collision system is awesome (push, group, c_ignore, (FLAG2)).

I standard wall up my entire level. Collision has always been flawed.

This is a rant I can support from all of my heart

AABB was perfectly usable for most games. I always thought that the latest A7 still had AABB because of the naming of "USE_AABB", but recently found it it uses ellipsoids instead.

So I took the only reasonable step for my game "Survive!":

I programmed my own AABB collision detection in lite-c. Its highly unoptimized but it works for the super small levels I have, and it includes the EVENT_ENTITY.
Its missing any kind of level-block collision though, so its worthless for you.

Superku, those features you mentioned are indeed nice, but collision group support is a very new thing. It was even worse before, trying to get c_trace and c_move to ignore a certain group of entites was a pain.


I'm having huge collision problems with my camera. I have a sphere model around it and I'm trying to use this to keep the cam from going through objects. Sometimes this looks horrible... bouncing around, gliding too fast...

I hate, really hate c_move
I'm currently trying to make workaround for ellipsoid problem...
But it sucks... Tried to use USE_AABB but I can't really see any differences, may be I got some errors...
OBB SUCK! Why they stoped using AABB?!

The new collision system using Nvidia Physix shoulkd solve all collision problems
Like Unity using collision engine for all collision managment !

Why does the code for using simple Physix collisions takes so
much time to be made for A8 ???

Even beginner can make Irrlicht engine use collision engine
in some hour with the tutorial !!

No time to waste !

No time to waste writing a tutorial or no time to waste posting one liners in a forum?

I have given usefull tutorials on my tutorial thread !
The thread don't interest you : it's your right !

BUT don't come and trash on what people give to others.

My tutorial thread is to help people, i have nothing to gain making it.
When i can improve what people can make in some way with some
critics i post.

That's my choice to gve positive and constructive posts !



You post just like that, like JustSid you have time to waste
to just search to annoy people freely like that !
Poor of you !
I think it's the same thing in your real life, you won't tolerate when people will not agree with you i htink !


Continue wasting your time annoying people !
Where is your interest ? your goal by doing that ?

If ou don't like other people post don't read them and don't espond to them !
It's what i do, when discussion going nowhere or that really
is annoying i just skip it : DO THE SAME WITH MY POSTS

You write so many lines and yet fail to answer my simple question?

Sorry, that isn't true. At least not for firoball, and at least not about all posts from JustSid.

What JustSid wanted to point you at is this - at least from my way of interpretation:
"Okay, you've read that it is such an easy approach with the collision system in irrlicht, but did you try it?"

Now from my point of view, because of my experiences I can say that nothing works the easy way, as it was said, when you try it yourself.

ratchet, don't get me wrong, I appreciate your posts and links to news of other engines etc., but many advices are missing the solid validation of doing it on your own to assure that it is actually working as others proclaimed.

As PhysX is already there, ratchet, feel free to use it for collision detection, just like in in irrlicht after "that tutorial", just a lot easier, as you just have to use it, no need to integrate anything anymore
Isn´t that great?

PhysX wouldn't work for me because there's too high of a chance that the player will fall over or start bouncing around the environment when I don't want him to. I want something I have absolute, unquestionable control over.

Simple AABBs fill this gap perfectly, so I'm looking into writing my own AABB system for block based levels.

Isn't it easier to ask for re-implementing it as an option for non BSP level in the Future Forum?
I've seen many requests the last months that have been fulfilled within a short time.

I could, but we're using A7 to build the game and that's already been succeeded by A8. Therefore if AABB support is put back into Gamestudio, it will end up in A8; not A7.

Still... In the long run, convincing spike to purchase A8 and convincing jcl to put AABB support back into Gamestudio would be easier than trying to write my own buggy, unoptimized AABB code.

EDIT: Here's my pitch to JCL:
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=359815

ratchet, don't get me wrong, I appreciate your posts and links to news of other engines etc., but many advices are missing the solid validation of doing it on your own to assure that it is actually working as others proclaimed.

Ok i htink i was wrong on saying it was simple !
I'm doing only basic game scripting and i don't implement Dlls
or physic engine or shaders.

So next time, instead of saying it's easy, i think i will shut up on these subjects

Shaders are simpler than any other kind of game scripting, IMHO. It's a different way of thinking, sure, but a small game will be hundreds if not thousands of lines of code. A small shader could be less than 10.

I agree that the built-in collision system is very limited in terms of usefulness. KarBOOM doesn't use any of the c_ functions at all. In future games of mine that require more complex character interaction with the environment, I see myself using c_trace, but doing all the collision stuff myself.

Jibb

As we see, I think there in no sense asking jcl to implement AABB or other shapes for collusion.. and that is really sad! Cause ellipsoid sucks!

If we keep pestering him, he'll cave eventually.

At the very, very least jcl could put AABB support back into gamestudio... I'm sure it can't be that hard to put back in.

Seriously...
WHY?
I just can´t get what you would need that for. As if the current one plus basicly any shape using physx would not be enough. Most other engines (for example Unity and ShiVa) do only have the ones supported by the physics engine and no one really complains.
There are much more important things for Gamestudio than collision shapes, so better learn coding, to do at least some things on your own. I btw really doubt that an AABB box would instantly solve all your problems and that the old system is gone without good reason...

i never used AABB, so i cant say what is better(and i couldn't use it with my commertial)! but there is onething i realy hate:
Why does the polygon-flag don't use polygon-colision-detection when the entity moves?(i know that's no bug and sorry for my bad english)
this makes my script x-times slower, to check which entitys the entity hits
thats one of the reasons why im trying to use physX for movent, fighting... EVERYTHING
xxxxxxx

Did you read Jibb's thread on the matter?

We need AABBs and/or cylinders because they have flat sides and flat bottoms. When you trace with an ellipsoid, you tend to get all kinds of crazy surface normals and data that's simply inaccurate. Ellipsoids just don't work for a number of game genres, specifically first person shooters.

physX is nice, but doesn't offer enough control for people who want to create proper actor movement, among other things.

Anyway, if ellipsoids are so great, why doesn't every other game engine in the world use them? Actually, why is Gamestudio the only game engine that uses them? Obviously they're not good for much. Last I checked, Unreal engine uses cylinders and id Tech uses AABBs. And they use them for a reason...

I actually think that the problem is not the lack of control, but the many possibilities to control things. The hard part is to setup the correct factors correctly to get the wanted simulation.

I didn´t state that ellipsoids are "so great". But in the end they also aren´t worse then especially AABB boxes.
I btw heavily doubt that the ellipsoidal bounding box is responsible for strange results when tracing.

PhysX is just too prone to problems. Even if you are able to properly set up enough fail safes to support normal actor movement in PhysX, you would be wasting tons of processing power, and the solution would be delicate and full of bugs. Full physics solutions tend to cause objects to bounce and jitter around their environment, which would make things look extremely ugly at best.

Once again, if this solution works well, why doesn't any other game developer use it?


Here's a test case: create a block in wed. Place an entity above the block, such that the entity is partly on top of the block but mostly off. Now use c_trace in combination with USE_BOX to trace straight downwards from the entity. A box or cylinder would give you a surface normal of 1, but since the trace is really using an ellipsoid you will get some crazy number between 1 and 0. That is bad.

So, once again: boxes and cylinders are used in every engine I can think of for a reason. They work 99% of the time, use little processing power compared to highly complicated solutions like PhysX, and are simple to create and maintain (relatively speaking). They are the optimal collision method for all types of games, from first person shooters, to platformers, beat-em-ups, sports games, and adventure games. So why does Gamestudio use ellipsoids, of all things?

Didn´t I already state above that Unity for example has no alternative to using PhysX for collision detection? Same for ShiVa, even though it uses ODE as far as I know. C4 on the other hand seem to offer alternatives, but the examples use its physics engine.
So there are indeed MANY developers using a physics engine for collission detection, as that actually is one of the main things such a physics engine is designed for. Which btw also includes raytracing...

If PhysX is all a developer needs, why does Gamestudio even have its own collision system?

Remember that their was a time when Phsyx were not integrated in the engine. This engine is very old, maybe older than you, Redeemer. Removing it now just just because there is an alternative way would be dumb.

easy fix. a invisible box scaled to the min/max values of the model to use for collision. lol.

I think, it could be 100 times better if OBB could be completely changed with physX collusion system.
But the thing is, that we still could use "C_" functions (c_move and so on), and without physics forces.
Plus additional mode to change BBOX's shapes, like box, ellipsoid, cylinder and so on...
The only thing is, that I think it's impossible... for two reasons:
* first cause I don't know how to implement that and is that even possible...
* second reason (the main one) is JCL

With the c_trace function you're able to do any collision system you can imagine on your own. So you've got the engines ellispoid collision system, the PhysX collision system plus the ability to implement any system you like. If you use PhysX you've got a complete physics simulation system, taking away a lot of these time consuming and complex tasks for you. Hence the level of control you have is reduced by this system. This is not a flaw but a necessary consequence of the system design.

Under the line you still have all possibilities to realize any collision you like. And I highly recommend not to see JCL as a problem. He is a very clever and intelligent person and he succeded to adapting this engine from the 90s up to today. That includes doing some pretty hard decisions and even choosing which feature to implement and which feature to abandon.

Initially this is true but I just made a little physics game in Unity and they take care of that. The quaternion class has a slerp member (spherical linear interpretation) that basically does an interpolation to smooth the movement over time. It works and you get rid of the jittering. There are also parameters to influence the smoothness.

Most of the time I don't want a full-blown physics simulation. I just want to move, stop when I hit something, and get the kinda information c_move gives me (normal, point of impact, who I hit).

Even if between some constraints and the like I could do it, I doubt it would be as efficient as a function dedicated to just collision detection.

Finally, c_trace with USE_BOX is a huge part of the issue, and AFAIK PhysX doesn't offer an equivalent function (I'd love to be corrected).

KarBOOM doesn't use any of the c_ or PhysX functions, and I can't see projects of mine in the near future using PhysX or any of the c_ functions, because I'd rather write my own if c_ doesn't pick up the pace.

Jibb

Well complicated !

Unity ,Shiva and some others uses physic engine, i've tried the demos and all runs really fine.
If you need very specific collision, you'll have to do it yourself; but for most cases : FPS, Car , the physic engines
goes well even on AAA games published !

So i htink it's ot each people to call the good Physix function
and adapt them to their A8 project !

Or switch engine or library if anything goes well ?
I don't know !
But for me i'll try to use Physix on my 3DGS sandbox tests !

Then I'm pretty glad I can do you favor. :-) You can use pXent_raycast for that purpose.

I actually think that it is common to use a physics engine and optimized collision geometry for everything. Especially for bigger productions than hobby projects.
I btw don´t see a big difference between a "full-blown physics simulation" and continuous collision detection including glide flag.

Last time I checked c_trace with use_box it worked just fine. If it really does return messed up normals, you should probably post it in the bug hunt?

I appreciate it, but USE_BOX is the main thing missing, and as far as I can tell that function is just a ray.
The problem is the normal returned is not the normal of the surface; it's the normal of the projected ellipsoid colliding with that surface. This is normally fine, except when we encounter an edge. Consider stairs: the normal returned by a c_trace without USE_BOX would be (1, 0, 0) or (0, 0, 1). Now try again with USE_BOX, where the box is bigger than a single stair, and you'll get a sloped normal (like (0.7, 0, 0.7)).

USE_BOX is great for a collision detection (that normal is ideal for ellipsoid collision detection), but really annoying when you actually care about the normal.

Jibb

you can also try USE_POLYGON on c_trace

I actually think that it is common to use a physics engine and optimized collision geometry for everything. Especially for bigger productions than hobby projects.

Well even iphone games for example made with Unity uses Physics and even some great RPG adventure semi open world runs great
with it

So well , no problem for Hobbyst projects even on small systems as Iphone.
For PC , it have lot of power to really handle physics without problems, even on low PC. Even old AAA games used Physics.

So yes, for my part if i can have primitives, world, Ray trace
made with Nvidia Physics i'll do it !

Well just my opinion !



For

PhysX needs to be installed first.
its not set up on many systems,

Good luck to get casual User Lucy to search, download and install a dangerous driver
to run a small Indy Game.

Its easier for her to click "next entry".

Using PhysX is overkill for many hobby games.
Requiering something extra to be installed is a deathnote.
(Its not Crysis or WoW, people will have very little patiance with a small Indy game)

The whole point Why Apple (iPhone etc) is so successful is because of
the design philosophy "It just works", for their products and software.

For simple games for simple puzzle, adventure games for lambda user i odn't think they expect great physics and A8 system is sufficient in this case.

FPS for example games are not for really lambda people , but more for people that like FPS games and lot of time, paly today FPS games. SO in that case no problem with Physix install !

Even some AAA RPG ask to install additionnal package like Physix and others.

In fact it really depends on your game type and the type of people you target to use or not Physix.
If really casual , not core gamer, well you can avoid i'm sure
Physix caus they don't exepect accurate or incredible simulation.

Once again is all up to you to decide

Yesterday I got curious and started making a test game with Gamestudio. In the game, the player entity uses a "collision mask" entity, that's shaped like a box and has its POLYGON flag set.

Unfortunately, I discovered that when other entities use c_move() for collision detection, they *always* perform collision detection as an ellipsoid, regardless of whether or not their POLYGON flag is set.

wwwwwhhhhhhhhhyyyyyyyy

use kniematic physics entites.

@Redeemer: JCL once said (and its also written in the manual) that you shall not use the polygon flag for dynamic (moving) entities.

"should not" does not mean the same thing as "cannot". JCL makes several recommendations and suggestions for the layout of your code in the manual, but not all of them are good advice (in my opinion).


Honestly, I'd really rather not have to resort to using a full blown physics engine when all I want to do is make a proper box trace across the level.

Honestly, I really don't like that jcl's isn't interested in community needs... I even hate that.
Same situation was with skills and "c_ignore" for A7, but ok, A7 wasn't supported (old version).
Now, there are a lot of users are asking for implementing different BBOX shapes, with good reasons...
We saying that ellipsoid isn't good for our needs! We don't want to use physics for our needs!
We made good examples, to explain all problems we face with ellipsoid BBOX, but is there any sense?!
WHY CAN'T WE GET ANY SUPPORT FROM HIM?! HE SEEMS ONLY IMPLEMENTING STAFF THAT HE LIKES!

[/rage]

I agree. I think the reason was because "complex" objects can get hooked on each other, however a box is not complex at all. I've used this method in A7, with no performance hits (that I noticed), and worked the same in A8. I mainly did this because of the way entity vs entity collisions are handled. My ultimate solution was to look at other engines, as I need to focus on my projects.

So, I've been playing around with physX for a while in a test project of mine, creating char entities with kinematic physics, rigid sphere entities, and static WMB entities.

And I've discovered, to my own dismay, that Gamestudio's implementation of PhysX sucks.

I'm sorry, it really does. Here's my biggest problems with it:

- pXent_movechar() is super inaccurate and uncontrollable. Many times an entity will stop moving before it even collides with an object, although I can get close to it anyway by sliding up against it. In addition, pXent_movechar() will cause entities to bump over and around objects, even if there's no way they can or should!

- WMB entities don't set the size of their BBoxes properly! As a test, I created a rigid, dynamic sphere body and started rolling it around on a bunch of WMB entities. To my annoyance, I found that the sphere will fall partly into a WMB entity! I know it's a problem with the WMB entity, because all other physics objects collide with the sphere normally. What's the deal?

- There's no way to control the size of an entity's BBox! seriously, pXent_setskinwidth() just doesn't work at all. In fact, it does the exact opposite of what it's supposed to do. I know, because I've tried passing it multiple different positive and negative values, fractional and non-fractional. But it doesn't work worth beans.

- With PH_CHAR and kinematic entities, boxes are treated like ellipsoids. This is exactly what I was trying to escape in the first place!

I faced all this problems a long time ago... But I though I was doing something wrong.
PhysX is implemented really badly... too many bugs, and too many little things.
But, hey, is there any sense in saying this? jcl doesn't give a s**t about our problems.
As I got banned at once for saying truth, he told me:
"Read manual and all of your bugs will flawlessly disappear."
But why even if I read manual, I can't just make another shape for BBOX (simply cause I want another shape)!
Why do I still get bugs with PhysX (jcl said that it's about year since it's implemented, year is good enough to make it stable)?

I didn't know Physix had so many bugs ???

Perhaps the best way would be a stable free physic engine by calling it's DLL and make our own implementation, behaviour ?

Strange i used Unity game engine physics character controller
and it's really fine, and works well ??

We not saying that PhysX has so many bugs! We saying that it's implementation in GS is sucks.

So why not changing the implementation in your own way
for character controller ? Or for all the physic stuff collision you need ?

C_move uses the shape of the mesh for collision detection. So your answer is to change the shape. In each of the eight corners of your mesh put a vertex there with med. Now as far as the engine is concerned you have a box.

That isn't actually how c_move works.

Jibb

I haven't got to test it but I'm not sure why it would not work.

Because c_move treats each moving entity as an ellipsoid.

Jibb

Yeah, c_move uses OBB collisions, which uses an ellipsoid. There was and AABB in A7, it had BOX hull, but A8 doesn't support it

No wonder my results are different. I still have A7. I thought the c_move problem was the same in both.

They same for me I got ellipsoid with and even without AABB, I guess I'm just using it wrong

Why can't I set min_ max_ for sprites D:<