WiP Shooter

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

WiP Shooter

Post by Marc » Mon Jan 31, 2005 7:34 am

Hi !

I'ld like to show you my progress on combining Newton with Ogre and my NetworkingLib:

Image

If you want to try it, you can download it from http://rochel.s83.deinprovider.de/wip/wip.7z


Known Issues:

Problems I'm aware of:

- Probably the system gets out of sync if tried in
Multiplayer mode. This is hard for me to try right now
because I have only 1 pc where Ogre an Newton run
correctly on.

- Gun 1 needs some tweaking, especially sometimes some
cubes don't react if you try to pull them. Moving a
bit around and trying it again makes it work.

Problems related to Ogre:

- Some cubes are flickering. I have no idea of the reason why.

- When switching the guns, their models stay fixed at
the position where you switched them in world space.
I don't know why. I define an overlay for each gun
and show and hide them according to the selected gun,
but instead of hiding the gun attached to the overlay,
it seems like it just disconnects the model from the
overlay somehow.

- Dynamical creation of Particle Systems are pretty slow,
at least the way I do it. If you take the second gun and
shoot, the framerate drops drastically on impact of the
projectile, exactly when a new Particle System gets
created. If I don't creat a Particle System then,
there is no slowdown.
Right now, my code to create a Particle System dynamically
looks like this and the first line is the one that takes
much time:

psys = ParticleSystemManager::getSingleton().createSystem(s, "Particles/Explosion");
vis = visualization->mSceneMgr->getRootSceneNode()->createChildSceneNode();
vis->attachObject(psys);


Problems related to Newton:

- The cubes sink into each other when you try to stack them.
I probably have to tweak the properties of the bodies
somehow.


If you have some tipps how to deal with these problems I'ld like to here about it.
If someone has some nicer models than I have and is willing to contribute them,
that'ld be cool :)

-
Marc
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Mon Jan 31, 2005 9:32 am

for particles :
At the beginning, creates a pool of Particle System, hide them.
Then when needed take one and show it at the right place.
0 x

User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

Post by Marc » Mon Jan 31, 2005 10:06 am

tuan kuranes wrote:for particles :
At the beginning, creates a pool of Particle System, hide them.
Then when needed take one and show it at the right place.
Yeah I also thought of that. But aren't the hidden particle systems also processed? If yes, isn't that a performance loss?

Actually, I feel this would be a workaround. Or is this the official method? Is there a design based reason why the creation of a particlesystem takes so long?
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Mon Jan 31, 2005 10:15 am

No, it just uses memory, this is the official method.
Pooling objects is THE solution in Game programming.

Flickering is Z-buffer problems with objects interpenetrating. (like in the barriers poles and cube at the beginning). You should make sure it doesn't happens.

In Ogre.log, it seems you've forgotten to include hardware skinning of the robot. (cg programs.)
0 x

User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

Post by Marc » Mon Jan 31, 2005 11:28 am

tuan kuranes wrote:No, it just uses memory, this is the official method.
Pooling objects is THE solution in Game programming.

Flickering is Z-buffer problems with objects interpenetrating. (like in the barriers poles and cube at the beginning). You should make sure it doesn't happens.

In Ogre.log, it seems you've forgotten to include hardware skinning of the robot. (cg programs.)
But for example cloning entities is fast, isn't it? I just thought there should have been some equal method for partsys. Or should I also pool entities instead of cloning them dynamically - perhaps it is faster, too?

I don't mean the ZBuffer flickering of the bariers. There are sometimes some of these normal cubes that just flicker. And they don't flicker like on and off, but like fullbright and halfbright. They also do that if you hold them with this gravity gun in front of you. They are not penetrating anything in that situation for sure. I thought it has something to do with lightning, but wasn't able to figure out what it is exactly.

Hardware skinning of the robot? I don't have a robot in my scene. Probably from some material definition I also don't use. I copied one example.material file from ogre's sample media dir.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Mon Jan 31, 2005 1:51 pm

Entities pool is faster too.
The mantra is :
Don't new or delete anything during game loop.
it leads to memory fragmentation, slower allocation, etc...
Pools are the answer for that. Look in ogre code for billboard pool for an example.
If you use network code you should have a connection pool, no ?

If it's lighting, check cube normals. do you scale your cubes ? don't, it makes bad normals.
0 x

User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

Post by Marc » Mon Jan 31, 2005 3:11 pm

tuan kuranes wrote:Entities pool is faster too.
The mantra is :
Don't new or delete anything during game loop.
it leads to memory fragmentation, slower allocation, etc...
Pools are the answer for that. Look in ogre code for billboard pool for an example.
If you use network code you should have a connection pool, no ?

If it's lighting, check cube normals. do you scale your cubes ? don't, it makes bad normals.
Ok then I'll pool everything. One question about that: What is the preffered strategy for handling the pool? Should I create lets say n things of everything and if I need n+1, create additional n of this type of things or should I create enough of every type at the beginning even though this may be far too much?

What do you mean by connection pool?

I don't scale the cubes in Ogre. Just load them from the .mesh file and attach them to a scenenode. I'll check the normals in the xml file.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Mon Jan 31, 2005 3:30 pm

Strategy is to double it each time you go over the max, so that you minimize fragmentation, alloc time, etc...

(After if you run out of memory or paging on hard drive too much, you can add a timer check to see if you can divide by 2 the pool when used object is under the new max for a while.)

Check HawkNL network library source code example called threadpool.c (or how to handle a large number in incoming requests.)
0 x

User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

Post by Marc » Mon Jan 31, 2005 5:30 pm

My experience is that in comparison to network speed, allocation times are negligible. I currently call a new on a new incoming connection to create an object representing the client on the server site. I doubt this a point where much can be optimized by pooling these client objects. But pooling particlesystems of Ogre seem to make a big difference.
0 x

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Mon Jan 31, 2005 5:56 pm

The mantra is :
Quote:
Don't new or delete anything during game loop.

it leads to memory fragmentation, slower allocation, etc...
Ok, I'm going to weigh in on this one :-)

My understanding is that OGRE does a lot of newing and deleting of objects inside of the render loop since it relies heavily on stl (i.e. deque, vector, list objects etc.). So to say that you should not new or delete anything is kind of misleading. It's happening, so you need to deal with it.

My personal take is, if you are experiencing memory fragmentation, etc. you should use another heap implementation that is better suited to your application. I've done this on other projects with a fair amount of success.

Also, pooling wastes memory. You can have a lot of "free" memory tied up with objects of type A, when you really need more memory for objects of type B.

I find pooling useful where the overhead of creating (or deleting) a object has significant overhead. This isn't usually the case where the overhead is mainly in heap allocation (although it does depend on the application).

Another use for pooling is to guarantee that the application has a certain minimum amount of memory available for use by pre-allocating it up-front.
0 x

User avatar
PeterNewman
Greenskin
Posts: 128
Joined: Mon Jun 21, 2004 2:34 am
Location: Victoria, Australia
Contact:

Post by PeterNewman » Tue Feb 01, 2005 12:01 am

Your full-bright/half-bright flicker: Are the objects nromal mapped? Did you create tangent vectors? We've had the same problem here, and it seemed related to creation of tangent vectors.

We never did get it working with that particular model, actually, as far as I know, though :(
0 x

User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

Post by Marc » Tue Feb 01, 2005 7:49 am

PeterNewman wrote:Your full-bright/half-bright flicker: Are the objects nromal mapped? Did you create tangent vectors? We've had the same problem here, and it seemed related to creation of tangent vectors.

We never did get it working with that particular model, actually, as far as I know, though :(
Ah I have forgotten to tell. tuan kuranes's tipp to check the normals solved the problem. For some reason, they all hab the length of 1.57 instead of 1. Normalizing them in notepad fixed the flickering. There is no normal mapping on that cube, just one texture.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Tue Feb 01, 2005 10:40 am

@Silent :
I do agree that pooling is not the only solution, and has drawbacks, thanks to pointing that out. But you must agree that coding your own efficient heap allocation algo is not the simplest thing to do.

Some readings that doesn't hurt:

Common C++ Performance Mistakes in Games

Memory Optimization
0 x

User avatar
Marc
Gremlin
Posts: 182
Joined: Tue Jan 25, 2005 7:56 am
Location: Germany
Contact:

Post by Marc » Tue Feb 01, 2005 11:59 am

By the way I figured out that the time is spent during creation of a particlesystem in loop like

for (i=0;i<quota;i++)
billboard = new Particle();

and quota is defined in these particle-scripts. If quota is high, like in the nimbus example I used (it is 10000 there), this takes quite a long time. I reduced it to 200 because the created pool in this loop is far too much, 200 also isn't reached. Now, the slowdown isn't noticeable anymore. 200 news seem to be ok ...

Just wondering if a new Particle[quota] wouldn't be faster there anyway...
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Tue Feb 01, 2005 1:37 pm

If it works without any problem (test with the particle demo), please submit a patch.
0 x

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Tue Feb 01, 2005 4:32 pm

tuan kuranes wrote:@Silent :
I do agree that pooling is not the only solution, and has drawbacks, thanks to pointing that out. But you must agree that coding your own efficient heap allocation algo is not the simplest thing to do.
Yeah, that went through my mind as I was writing my response. However, I thought it important for people to get multiple perspectives on this issue since it's come up a few of times now.

I don't have Powerpoint on my home machine (home with a cold :-) ). I assume that's what the ".ppt" extensions refer to. I'll have to check out those links later.

Thanks.
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Tue Feb 01, 2005 5:00 pm

"multiple perspectives"
Cannot agree more !

If you can (dsl or cable line), download openoffice, It reads ppt very well (that's what I do use).
Anyway, Pdf version of the second here
0 x

User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands

Post by :wumpus: » Tue Feb 01, 2005 5:56 pm

Silent wrote: I don't have Powerpoint on my home machine (home with a cold :-) ). I assume that's what the ".ppt" extensions refer to. I'll have to check out those links later.

Thanks.
You can open ppt files with openoffice, which you can download for free for windows, linux, mac.
0 x

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Tue Feb 01, 2005 6:00 pm

Thanks! I'll grab a copy (of OpenOffice) shortly. First, it's time for some lunch :-)
0 x

Post Reply