Custom joints vehicle and weak joints

[kallaspriit]

I changed the solution so MinimalOgreNewt executable remains in demos/MinimalOgreNewtApplication and there are bat files in demos/bin/Release and demos/bin/Debug. Also moved around some resources. Be sure to update from SVN

[Julio Jerez]

excelent! it work correctly now, ver nice
OK in couple of hours i will post the new archive with the improved player.

[Julio Jerez]

Kella I am having so many problems with Ogre architecture.
here is one of the them, in the OgreRoot the mFrameListeners container is a stl::set, this is huge mistake, it should be a List or a Vector and each Listeners should be added to the end of the array.
Sets are only useful for when you are dealing with lot of items, but an application will only have very few listeners so the benefit of a set is not justified while they add lot of chaotic behavior to the end application.
The Listeners in the set are sorted by the pointer, the causes that the end application does not know the order or execution.
In one of the demos there are three listeners, one is the timestep calculator, the second is the Newton Listener, and then there is the controller update.
Here is the problem it does not matter what order they are added to the ListenerSet, the order is not the same even from machine to machine or form run to run of the same same app.
Ideally you want the order to be timer, physics and control, but I get Timer, control, physics and there is not way to change that since the memory allocation is generating the pointers in different heaps.
I am considered to be a Moron in the Ogre community, maybe you can let them knows about this issue an either they can tell you a solution or change the set to be a vector or a list.

[PJani]

Kella I am having so many problems with Ogre architecture.
here is one of the them, in the OgreRoot the mFrameListeners container is a stl::set, this is huge mistake, it should be a List or a Vector and each Listeners should be added to the end of the array.
Sets are only useful for when you are dealing with lot of items, but an application will only have very few listeners so the benefit of a set is not justified while they add lot of chaotic behavior to the end application.
The Listeners in the set are sorted by the pointer, the causes that the end application does not know the order or execution.
In one of the demos there are three listeners, one is the timestep calculator, the second is the Newton Listener, and then there is the controller update.
Here is the problem it does not matter what order they are added to the ListenerSet, the order is not the same even from machine to machine or form run to run of the same same app.
Ideally you want the order to be timer, physics and control, but I get Timer, control, physics and there is not way to change that since the memory allocation is generating the pointers in different heaps.
I am considered to be a Moron in the Ogre community, maybe you can let them knows about this issue an either they can tell you a solution or change the set to be a vector or a list.

Im dealing with this problem too. That why I am writing special TaskManager with priorities for Ogre::FrameListener and for profiling slowest listener of my application. FrameListenerTaskManager will not be finished so soon at least 5 hours not.

[Julio Jerez]

I there a reason why this is that way, you would think this would be a very common problem for any one using more than one listener, speciallly people using multithread code.
has any one posted this over ether ogre forum?

[PJani]

I there a reason why this is that way, you would think this would be a very common problem for any one using more than one listener, speciallly people using multithread code.
has any one posted this over ether ogre forum?

Im looking right now what is the reason for std::set. I have never tought until now why std::set is used instead of list or vector.

EDIT: i use more than 20 FrameListeners but i have never have problem with ordering, maybe becouse i use windows and windows stacks new addresses.

Now i know why i the hell every time i compiled my application, different box destruction happend.

[PJani]

Here is debate of this problemhttp://www.ogre3d.org/forums/viewtopic.php?f=4&t=29564&p=208272

[Julio Jerez]

So this is known problem that have being linger for years and the creator refuses to fix it given real reason other than stoborness.

by sinbad » Sat Mar 10, 2007 1:57 pm
It's a fair point, but not exactly super-high on the radar since a) the number of frame listeners will be small and b) they only get called twice a frame. Chance of any perceivable performance difference between set and vector: zero

The docs have always said that framelistener call ordering is undefined. It's one of the things that encourages people to think about their own event dissemination procedures rather than registering many frame listeneres.

I take the point, but I don't plan to change it just at the moment because I don't think it's that important. Submit a patch and I might do it for Shoggoth

This is one of the self appoint expert that had participated on the slander of my name all over the internet because I do not make open source code,
and here you find him acting like a Tiran on a open source project, So much for Open source.
This man does not seems to have any experience doing programming for serious app, given that if you use Ogre for rendering you do not have a choice that to code you logic in a listener,
you cannot decide to make the order random form the application view point.
This is total short sight blonder, and it is beyond my comprehension why someone would refuses to simple change the type from a Map to a List or a Vector,
He already said that Listener are called once per frame, and that there cannot be to many in the application, plus he said that the order is undefined so the change cannot possible affect any appication.
Vetor iterator are faster (is you count nanosecund), so why refusing fixing it? This is irrational behavior.

The only choice he leaves is to make real the logic in one listener and even that is out of question because Ogre itself add one listener to the list.
This makes listeners completely useless.

[Julio Jerez]

Basically the only way to get this right with the Ogre Architecture is by no doing anything in the Frame listener and let it pass.
Then do all the controlling in the frameRenderingQueued method
This is the Render one Frame loop.

Code: Select all

    bool Root::renderOneFrame(void)
    {
        if(!_fireFrameStarted())
            return false;

     if (!_updateAllRenderTargets())
      return false;

        return _fireFrameEnded();
    }

First evaluste all the Listens FrameStart Mesthod but they can be out of order, then it call update render target but render target evaluser the evert before rendering so the logic can be coded there.

Code: Select all

    bool Root::_fireFrameRenderingQueued(FrameEvent& evt)
    {
      // Increment next frame number
      ++mNextFrame;

        // Remove all marked listeners
        std::set<FrameListener*>::iterator i;
        for (i = mRemovedFrameListeners.begin();
            i != mRemovedFrameListeners.end(); i++)
        {
            mFrameListeners.erase(*i);
        }
        mRemovedFrameListeners.clear();

        // Tell all listeners
        for (i= mFrameListeners.begin(); i != mFrameListeners.end(); ++i)
        {
            if (!(*i)->frameRenderingQueued(evt))
                return false;
        }

        return true;

    }

I will do that way buy this is an absurd, in my opinion all the listeners and all the events should be dispatched in the same order that are created.

[Julio Jerez]

Well I am not going to make that change at this time, but I really, really recommend t eth Ogre owners to fix that design flaw.
If I start spending time on that It will take me away from what I was planning.

Anyway I have the Played demo completed, It use the BSP level that come with Ogre, plus I also added two of the mesh I use for the Newton SDK.

You need to get the latest Newton SDK 2.16 because I made some improvement to the Player joint.

In the Archive you get.
http://www.newtondynamics.com/downloads/OgreNewt.rar

The Player Joint with a demo in full game level,
OgreNewt::World Update at smooth Frame rate with interpolated render frames.

I made some other changes but those are not that important


If after you test this and check it in SNV It is is RayCast car time.

[kallaspriit]

You do not have to use a single frame listener and in my own application, I don't. Have you read Application.cpp in my MinimalOgreNewt project? That shows the minimum that needs to be done to get a simple application running and anyone can extend that with any design and logic they see fit. In my application, instead of framelisteners I have game states that events are passed to. Here are the headers:

StateManager.h

Code: Select all

class StateManager : public Ogre::Singleton<StateManager>
{
public:
   StateManager();
   ~StateManager();

   bool registerState(GameState* state);
   const std::map<GameState::Id, GameState*>* getRegisteredStates();
   GameState* getActiveState();
   GameState::Id getActiveStateId();
   bool isAcceptable(GameState::Id id);
   bool isAcceptableInstantly(GameState::Id id);
   bool requestState(GameState::Id id, bool unloadPrevious = true);
   bool forceState(GameState::Id id);
   void exitAllStates();
   void destroy();

   static StateManager& getSingleton(void);
   static StateManager* getSingletonPtr(void);

private:
   GameState* activeState;
   GameState::Id activeStateId;
   std::map<GameState::Id, GameState*> states;
};

GameState.h - actual game states extend this and are registered with the StateManager

Code: Select all

class GameState : public OIS::KeyListener, public OIS::MouseListener, public Ogre::WindowEventListener
{
public:
   enum Id { NONE, LOADING, INIT, MAIN_GUI, SANDBOX, TERMINATE };

   GameState() { paused = false; valid = false; };
   virtual ~GameState() {};

   virtual GameState::Id getId() = 0;
   virtual Ogre::String getName() = 0;

   virtual void enter() { valid = true; };
   virtual void exit() { valid = false; };

   virtual void update(unsigned long frameTime) {};

   virtual void pause() { paused = true; };
   virtual void resume() { paused = false; };
   virtual bool isValid() { return valid; };
   virtual bool isPaused() { return paused; };

   virtual bool isAcceptable(GameState::Id state) { return true; };
   virtual bool isAcceptableInstantly(GameState::Id state) { return true; };
   virtual bool changeState(GameState::Id newState, GameState* state) { return false; };

   //virtual bool requestSubState(GameState* state) {return false; };
   //virtual bool deactivateSubState(GameState* state) { return false; };
   //virtual bool deactivateSubState(Ogre::String name) { return false; };

   virtual bool keyPressed(const OIS::KeyEvent &e) { return true; };
   virtual bool keyReleased(const OIS::KeyEvent &e) { return true; };

   virtual bool mouseMoved(const OIS::MouseEvent &e) { return true; };
   virtual bool mousePressed(const OIS::MouseEvent &e, OIS::MouseButtonID id) { return true; };
   virtual bool mouseReleased(const OIS::MouseEvent &e, OIS::MouseButtonID id) { return true; };

   virtual void windowMoved(Ogre::RenderWindow* rw) {};
   virtual void windowResized(Ogre::RenderWindow* rw) {};
   virtual void windowClosed(Ogre::RenderWindow* rw) {};
   virtual void windowFocusChange(Ogre::RenderWindow* rw) {};

protected:
   bool valid;
   bool paused;
};

I am still a beginner in the field and not sure whether this is the best approach, but it works and is quite versatile.

I will check your changes and commit to SVN if everything is good

[Julio Jerez]

You do not have to use a single frame listener and in my own application, I don't. Have you read Application.cpp in my MinimalOgreNewt project? That shows the minimum that needs to be done to get a simple application running and anyone can extend that with any design and logic they see fit. In my application, instead of framelisteners I have game states that events are passed to

I do not want to make a case out of Ogre Architectural design, but the design is just ill.
The frame listener is the end application code game logic that happens once per frame, event are not supposed to happen once per frame, in fact event should be asynchronous.
If anything, even should be buffered or queues, and issue them as the very first thing when the frame start.

The result of the current order is that anyone using multiple frame listeners will never be able to coordinate a complex logic where one system do stuff in one listener and other listener depend on those results.
Basically it renders Ogre a very small engine only subtitle for In house or home brew application when everything is costume made, but useless for third party middleware plugging.

Ideally a Plug-in in will be designee in one listener and it is up to the end user to use as it if to sub classed it.

Anyway Let us no focus on the Ogre design, I will way until you test the last update and committed or report what is incorrect and them I will update and move to the Ray cast car.

[kallaspriit]

I made some minor changes and updated SVN. Make sure to check out a new copy from SVN before doing your next updates or our versions will drift apart.

I see you have made many updates. The character controller is beginning to look pretty good, jump and crouch is still needed.

Also, the demos desperately need a better camera, why have you reversed the mouse axis in some demos? For example, in Demo02, the camera only moves when left mouse key is pressed and moving the mouse left moves the view to the right (same with up-down), why is that good? Same problem in Demo03 and Demo09, the camera barely works in Demo06 (also buoyancy does not work). What about the camera movement in MinimalOgreNewt demo - the camera moves in simple FPS style and and picking is enabled when holding down CTRL. I think a proper camera is needed and should be unified across the demos along with picking (for that, the Picker class I made for MinimalOgreNewt could be used in demos\MinimalOgreNewtApplication\source\Picker.cpp). What do you think about the camera problem?

Anyway, keep up the good work

[Julio Jerez]

I only touch the camera code for demos I worked the most: joint, raycast and player.
I made the mouse move work when you press a mouse bottom because for debugging it is much better, when you are debuging and an object is in a problematic place you can just leave the mouse alone and step in the debugger,
but when you make the mouse fixed to the camera it is almost imposible to debug anything (at least for me).

The camera is not really my major concern, after i am trought it can be changed back to the way Ogre community like it best.
I will fix the other demos so that they use the same camera motion plus I will add the missing funtionality for the player controller joint.
Plus there is still one more bug left in the player joint that I am working on

anyway I will update and continue, maybe next update will have teh full and final Player plus the Raycast car.
The good thing is that any change I made to teh library now are automatically either inherited by the wraper or we just have to edit or add the corresponding joint
which was teh goal, but I still wnat to make all demo look as nocer as they can to make it eassy fo rteh end user.

[PJani]

Anyway why there is no more time slicing world updating? Just asking!