NxOgre 1.8 "LeJean" idea

betajaen

26-01-2011 19:04:43

Hello chaps,

So "BuggySwires" is nearly done, the remaining issues I know about are:

- CC Callbacks
- CC Automatic callback; moving boxes properly.
- CC Yawing.
- Renaming AnimatedBackgroundCharacterController to AnimatedCharacterController or AnimatedCharacter.

It won't take long to finish them, so I've been thinking about the next version. I like this idea of using a point release for a centering around a single goal, and Anuga in my mind has been about serialisation; to file, to streams and to scenes.

However, I've been using the NxOgre API more - from a user point of view, and noticed some inconsistencies, some missing features and some newer features of PhysX that I have missed.

I'm seriously considering bumping [b]Angua[/b] to 1.9, and doing an audit of the code for 1.8. Going through all the classes, and making sure they work as intended. Full inline documentation. Upgrade classes, and a general thorough going through, with as a little of an public API change as possible.

I'll take SimpleShapes for example;

They represent the NxBox, NxSphere, NxCapsule classes. They are meant for helping with collision detection, and giving shapes to non-RigidBody based classes; Character Controllers and Forcefields. "Simple" is a silly word for it, and prefixing them with Shape would be better. I realise that NxOgre used to use the prefix for shape for the actual shape system, but that was pre-Bloody Mess.

Also; there is a utility library called NxUtil lib, that gives plenty of functions for shape based functions. Intersection checking, volume calculation, mass calculation,etc. It would be great if those would be bound together.

So in PhysX you'd do:
NxBox box;
box.extents.set(1,2,3);
NxReal density = 1.0f;
return NxUtilLib::NxComputeBoxMass(box.GetExtents(), density);


But in LeJean you'd do:

BoxShape box(1,2,3);
return box.mass(1.0f);


So these are the types of things I'd like to do in [b]"LeJean".[/b]

Comments, Questions?

betajaen

26-01-2011 19:18:16

Some ideas:

- Port Ogre Math classes into NxOgre. Currently upgrading the Vec3/Quat in BuggySwires, via OgreMath. But I'd like a more consistent API.
- Remove references to Angua; PrimaryScenes/AuxiliaryScene, SceneLink and KinematicSceneLink.
- Remove type2id
- Condense some of the related cpp files into one. Triangle/Tuple , Vector/Map/MultiMap and VertexBuffer/IndexBuffer/etc
- Reduce the amount of classes for ErrorSystem. Just two will do, not ~six.
- Replace the "failure code" with exceptions.
- Have a look at the machine classes.
- Better TimingSystem. Have a "willPhysXSimulateInThisTimeStep" function. Simplify TimeStep class.
- Remove the need for "Allocator" system. Malloc will be fine.
- Have a look at the "Reason" class. It's a good idea. But doesn't cover all of the Description classes.
- Implement all of the types of joints.
- Remove empty cpp files NxOgrePhysXBuffer NxOgreXFunctions

betajaen

26-01-2011 19:22:47

- Better Wheel System. Machine class to replace with some sort of Vehicle designer?
- Better way of handling foreign terrains. Use the Ogre image class in Critter to load in images as heightfields?

spacegaier

26-01-2011 19:44:54

Sounds great! Always good to get rid of inconsistencies and do some checks (*points_at_the_ogre_papercut_initiative*).

Will LeJean then be 1.8.B? Or how is the numbering progressing?

betajaen

26-01-2011 19:47:28

1.7 is BuggySwires, and 1.8 would be the LeJean and 1.9 Angua. The 4 digit number after each version is the build id; basically the number of times I hit Build in Visual Studio. It's reset to a 1000 each time I bump up the version number.

Papercuts is something I'd like to do, much more informally though. Just suggest something, and I'd probably put it in. But I do that normally anyway.

spacegaier

26-01-2011 20:01:14

Ah, right...BuggySwires is 1.7. Sorry for mixing that up ;) . Got way too many numbers flying around right now (Ogre, Ogitor, NxOgre, ..) :D .

deshan

27-01-2011 03:51:02

Extremely like the idea of LeJean. fully completing the api sounds really good. thank you very much for making these

I have a one question.
Do you have any plan for adding a ragdoll creation for critter?

~deshan

betajaen

27-01-2011 08:05:33

That's more of an Angua thing, since Ragdolls need to be loaded and saved to disk, and Angua is all about serialisation.

deshan

27-01-2011 17:05:36

That's more of an Angua thing, since Ragdolls need to be loaded and saved to disk, and Angua is all about serialisation.
I see.. Didn't knew Ragdolls needs serialization. Thanks for the point.

betajaen

27-01-2011 18:17:26

Well, the one that I want to make will need it. :D

Diabolikal49

29-01-2011 18:19:50

Sounds good so far, I haven't actually heard of NxUtil, so it would be nice to see which shape functions will be included.

dragutux

06-02-2011 04:58:28

i have a suggestion : lots of missing stuff from the physx sdks notably tutos, samples (nx tank :D) etc.
so working on those too to be implemented should be nice. willing to do some :P

dragutux

06-02-2011 05:01:01

and to be more concrete :
- the cars & trucks examples exist in the base sdks of physx (2.8.1 & 2.8.4 repartited in those)
- a chopper & a plane is fairly easy to do too

spacegaier

06-02-2011 11:14:27

You know that betajaen has already done quite some tutorials, right? I am sure more are to come :) .

https://github.com/betajaen/nxogretutorials

betajaen

06-02-2011 13:33:44

I have something in mind for the tutorials, and mostly started on it.

But I have quite a few ideas for LeJean which I want to write down into code, before I forget them. One of them is from Angua, which is streaming; which from streaming you can have scene to scene sharing or networking support. I thought whilst I'm redesigning some of the core classes, I'd implement streaming at the same time.

mephisto

09-02-2011 17:13:16

Define this functions

NxOgreD6Joint.h

void setDrivePosition(const Vec3& position);
void setDriveOrientation(const Quat& orientation);
void setDriveLinearVelocity(const Vec3& linearVelocity);
void setDriveAngularVelocity(const Vec3& angularVelocity);

dragutux

09-02-2011 18:32:14

request : docs/api online.. (hard to backport interesting projects else)
also : advanced tutorials html (so we can understand more the meaning of every demo and what are the important
steps).

i'm requesting as a newb needing more docs than what is present :)

spacegaier

09-02-2011 19:44:45

More detailed tutorials might follow once the development work is mainly done. Right now, betajaen and I agreed that he will first provide those rather minimalistic demos as the PhysX SDK does as well (and they are quite similar so that the documentation in the PhysX SDK applies to NxOgre's demos as well).

Once I finally find some sparetime I will probably start porting my BloodyMess tutorials over to the latest NxOgre version to support beginners and get them up to speed so that they can then learn the really advanced topics via betajaen's minimalistic samples.

betajaen

09-02-2011 20:02:42

I quite like the book idea I have going on, the intention was to make my own tutorials from scratch. As the lessons don't really have a good order, and require you to have prerequisite knowledge; vector math, reals, relativity, kinetic motion, etc. My book idea teaches you those then gets into working with NxOgre.

But my main priority is to get LeJean the idea of the ground.

dragutux

10-02-2011 07:08:03

i understand.. can i bug either one of you ? i have a project i'd really like to take back to a working state but due to a very old nxogre it doesnt compile and i am out of ideas on how to fix it .. project is karma3d (regular forum search will bring it up) would be nice if someone helps me, as for now i have an issue with the camera creation here code :

//Create sphere for collision
//Properties
NxOgre::RigidBodyDescription descriptionSphere;
descriptionSphere.mRigidbodyFlags |= NxOgre::DynamicRigidbodyFlags::DisableGravity;
descriptionSphere.mRigidbodyFlags |= NxOgre::DynamicRigidbodyFlags::FreezeRotation;
descriptionSphere.mMass = *Settings::getSingletonPtr()->mCamMass;
descriptionSphere.mDensity = 0;
descriptionSphere.mLinearDamping = *Settings::getSingletonPtr()->mCamLinearDamping;
descriptionSphere.mAngularDamping = *Settings::getSingletonPtr()->mCamAngularDamping;

/*Create it.
cube1m mesh wont show anyway.
NxOgre::Vec3(0,2,3) indicates the camera position*/ //@todo spawn at player
// line bellow : kind of a bug fix i was trying to use ...
//mvpCamSphere = Critter::RenderSystem->createBody(BoxDescription(1,1,1), globalPose, "cube.1m.mesh", bodyDescription);

mvpCamSphere = Critter::RenderSystem::createBody(new NxOgre::Sphere(*Settings::getSingletonPtr()->mCamRadius),
NxOgre::Vec3(*Settings::getSingletonPtr()->mCamStartPosX,Settings::getSingletonPtr()->mCamStartPosY,Settings::getSingletonPtr()->mCamStartPosZ)+NxOgre::Vec3(Ogre::Vector3
(*Settings::getSingletonPtr()->mPlayerSpawnPointX,*Settings::getSingletonPtr()->mPlayerSpawnPointY,*Settings::getSingletonPtr()->mPlayerSpawnPointZ)),
"cube.1m.mesh", descriptionSphere);

mvpCamSphere->getEntity()->setVisible(false);

//Set Collision Flag to group 2
NxShape* const* s2 = mvpCamSphere->getNxActor()->getShapes();
(*s2)->setGroup(2);



Compile log :
1>CameraHandler.cpp
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(110) : error C2664: 'NxOgre::Sphere::Sphere(NxSphereShape *,bool)' : cannot convert parameter 1 from 'float' to 'NxSphereShape *'
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(111) : error C2100: illegal indirection
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(115) : error C2039: 'getEntity' : is not a member of 'Critter::Body'
1> c:\sdk\projects\projectkarma\karma\dependancies\critter\source\critterbody.h(53) : see declaration of 'Critter::Body'
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(115) : error C2227: left of '->setVisible' must point to class/struct/union/generic type

betajaen

10-02-2011 08:16:06

Basically, your code should be more like:

(Detritus API)

Critter::BodyDescription descriptionSphere;
descriptionSphere.mDynamicRigidbodyFlags += NxOgre::DynamicRigidbodyFlags::DisableGravity;
descriptionSphere.mDynamicRigidbodyFlags += NxOgre::DynamicRigidbodyFlags::FreezeRotation;
descriptionSphere.mMass = *Settings::getSingletonPtr()->mCamMass;
descriptionSphere.mLinearDamping = *Settings::getSingletonPtr()->mCamLinearDamping;
descriptionSphere.mAngularDamping = *Settings::getSingletonPtr()->mCamAngularDamping;

NxOgre::SphereDescription sphere_shape_desc;
sphere_shape_desc.mRadius = *Settings::getSingletonPtr()->mCamRadius;
sphere_shape_desc.mGroup = 2; // Set Collision Flag to group 2

NxOgre::Vec3 position;
position.x = *Settings::getSingletonPtr()->mCamStartPosX;
position.y = Settings::getSingletonPtr()->mCamStartPosY;
position.z = Settings::getSingletonPtr()->mCamStartPosZ;

mvpCamSphere = Critter::RenderSystem->createBody(sphere_shape_desc, position, "cube.1m.mesh", descriptionSphere);
mvpCamSphere->getSceneNode()->setVisible(false);


I don't understand why you want to hide your SceneNode though, if you don't need a mesh just omit the "cube.1m.mesh" from the createBody line.

If you need further help, please start a new thread.

dragutux

10-02-2011 13:52:04

as said, i need to port this code to 1.7...........

betajaen

10-02-2011 14:19:05

Oh, well that should work in BuggySwires, apart from the last line. Which would be "mvpCamSphere->getNode()->getSceneNode()->setVisible(false);"

dragutux

10-02-2011 14:40:24

still having issues with the createbody..

so far test results
for the code you suggested
]mvpCamSphere = Critter::RenderSystem->createBody(sphere_shape_desc, position, "cube.1m.mesh", descriptionSphere); produce this errors :

1>CameraHandler.cpp
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(115) : error C2819: type 'Critter::RenderSystem' does not have an overloaded member 'operator ->'
1> c:\sdk\projects\projectkarma\karma\dependancies\critter\source\critterrendersystem.h(47) : see declaration of 'Critter::RenderSystem'
1> did you intend to use '.' instead?
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(115) : error C2232: '->Critter::RenderSystem::createBody' : left operand has 'class' type, use '.'
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(116) : error C2039: 'getSceneNode' : is not a member of 'Critter::Body'
1> c:\sdk\projects\projectkarma\karma\dependancies\critter\source\critterbody.h(53) : see declaration of 'Critter::Body'


the code that seems the most consistant and working according to the hierarchy :
mvpCamSphere = Critter::RenderSystem::createBody(sphere_shape_desc, position, "cube.1m.mesh", descriptionSphere);

but it produce :
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(114) : error C2352: 'Critter::RenderSystem::createBody' : illegal call of non-static member function
1> c:\sdk\projects\projectkarma\karma\dependancies\critter\source\critterrendersystem.h(94) : see declaration of 'Critter::RenderSystem::createBody'

dragutux

10-02-2011 14:46:28

i also added mvpCamSphere->getNode()->getSceneNode()->setVisible(false);

now : (end of function)
//Set Collision Flag to group 2
NxShape* const* s2 = mvpCamSphere->getNxActor()->getShapes();
(*s2)->setGroup(2);

produce :
1>c:\sdk\projects\projectkarma\karma\source\camerahandler.cpp(119) : error C2144: syntax error : 'NxShape' should be preceded by ';'

but i think this is normal since the mvpscamsphere isnt fixed yet

also : remember the old coded created a new sphere element .. its for placing the camera box..

betajaen

10-02-2011 14:56:06

You don't need to do that. I told it so in the description. Also Shape should have a setGroup function already, so you don't need to get PhysX involved. Infact unless you have a good reason, there is no need to link to PhysX in your application.

"Critter::RenderSystem" is a typo, just use mRenderSystem or whatever pointer you have assigned for it.

dragutux

10-02-2011 15:15:40

error fixed with this :

mvpCamSphere = mRenderSystem->createBody(sphere_shape_desc, position, "cube.1m.mesh", descriptionSphere);

mrendersystem was added defined in camerahandler.h

cdreid

12-02-2011 03:26:13

I love the idea of going through the api. A "bugfix* and "correction" release. I gave up on nxogre because of the memory errors in my last post. The problems were unfixable without learning every detail of the api and the wrapper.

A few suggestions from a HUGE fan:

Is there any chance you can natively incorporate on the fly or builtin ogre/nxogre mesh/terrain conversion. This killed my plans as ogre and nxogre are geared currently around fps/rpg "levels". This would make editable terrain trivial.

Allowing a dedicated team to help. This is something opensource project coders usually fight (spring project/ogre/opensim etc) but theres a lot of expertise out there. A "tutorial/docs" team could take a lot of the boring stuff off your hands like keeping the wiki updated/accurate, creating more and better tutorials (yours are great but have to be generic and rare so you can code.. you know.. the actual api).

Id also suggest a debugging team dedicated just to that. Im not talking a lot of full time people im talking people who volunteer who you find acceptable who maybe put in a couple hours a week helping out.

Youve done an amazing job pretty much singlehanded btw. I have been amazed from the start at this whole community and its coders.

betajaen

14-02-2011 22:00:33

I started experimenting with providing an alternative C API (switchable via compile option). Turns out if you do it correctly, you can operate NxOgre by anything.

This is LeJean controlled by Ruby;

require_relative "NxOgreLib"

world_desc = NxOgreLib::WorldDescription.new
world_desc[:no_hardware] = 0
world_desc[:gpu_heap_size] = 16

world = NxOgreLib::World.createWorld! world_desc
world.setAssertionPolicy :breakpoint
puts world.getAssertionPolicy.to_s

world.advance 0.1667

NxOgreLib::World.destroyWorld!


Result

N:\nxogre.org\LeJean\NxOgre\sdk>test.rb

[
assertion_policy = 0 ,
cooker_thread_mask = 0,
hardware_maximum_convex = 2048,
hardware_maximum_page = 256,
no_hardware = 0,
per_scene_batching = 1,
gpu_heap_size = 16,
mesh_cache_size = 4294967295,
hardware_page_size = 65536
]

[NxOgre] Creating PhysX SDK using PhysX 2.8.4
breakpoint
Advancing time by 0.1667
[NxOgre] Stopping PhysX SDK
[NxOgre] NxOgre and PhysX Objects destroyed



I think I may continue with it.

deshan

25-03-2011 13:57:25

For Lejean Tutorials

4 wheel Vehicle :)

mephisto

25-03-2011 19:13:55

I would suggest more Math classes flexibility : for exemple between Matrix44 and Vec3 ( Matrix44 += Vec3 - translation of Matrix44 )

betajaen

25-03-2011 20:42:31

I've actually been borrowing quite a few of the math classes from Bullet.

mephisto

26-03-2011 08:04:17

For joints : functions like setGlobalAxis, setGlobalAnchor ... in the JointDescription also.

betajaen

26-03-2011 08:46:16

There is an existing helper class in BuggySwires that does that already.

mephisto

26-03-2011 08:55:50

Yes and its great .setting local anchors is by far more difficult. But in NxOgre we set the globalAnchor like this :

NxOgre::D6Joint* j; j->setGlobalAnchor

in physX :

NxD6JointDesc dscc;dscc.setGlobalAnchor and NxD6Joint* j; j->setGlobalAnnchor .

Here is my work with joints to make a tank :

http://www.youtube.com/watch?v=lQt78acZdOU

betajaen

26-03-2011 09:03:51

No, I mean there is a helper class that works on joint descriptions already.

NxOgre::RevoluteJointDesc desc;
// ...
NxOgre::JointHelper::setGlobalAxis(desc, Vec3(0,1,0), body_a, body_b);


But an in class one may be just as useful.

mephisto

26-03-2011 09:05:09

Oh thanks.

mephisto

26-03-2011 09:16:18

It's just a suggestion but Nx variant with only one parameter is more flexible . It does not requier bodies to be created.
The thing is to separate configuration step and creation step (bodies, joint ... etc... )

mephisto

26-03-2011 10:22:15

The new thing in BuggySwires' Critter rendersystem is that BodyDescription contains member mNode. To reuse same body description should we set mNode = NULL each time we create a body with?

betajaen

26-03-2011 10:25:49

If mNode is NULL then it will create it, if it's not it will use it. You can use reuse BodyDescriptions but you would have to change mNode. Critter can't know your reusing descriptions, so you'll have to set mNode to what you want it to be each time.

betajaen

12-04-2011 08:57:13

Datatypes

Thought occurred to me last night in a dream, borrow the idea of "Datatypes". Simply put, allow NxOgre to read in any mesh, heightfield or scene fileformat providing there is a datatype that can read it, convert it quickly in memory to the PhysX file format and continue. Obviously, the most simpliest way would for everyone to use NXS fileformats but the exporters aren't very good, and there are no .flower exporters for max or maya.

At least this way, the API is open and in debug mode it can save the converted files to disk instead of memory, so the user can use those instead. Critter would come with an Ogre mesh datatype.

mephisto

17-04-2011 13:07:42

In the inline documentation of WheelShape it says "suspension travel 1.0f by default" but it is set to 0.0f by default. This is a small thing but I lost few minutes asking myself why the suspension doesn't work :)

mephisto

17-04-2011 21:47:09

if its possible something like Ogre::Vector3 NxOgre::Vec3::toVector3();
I dont know if its correct but something like this would be usefull : NxOgre::Matrix44 m44; m44.x = 3.0f; m44.y m44.z ( to specify position )

betajaen

18-04-2011 07:37:26

Vec3 v1(1,2,3);
Ogre::Vector3 v2 = v1.as<Ogre::Vector3>();


Matrices don't work like that I'm afraid. But in LeJean, I'm switching to "transforms" which has an accessible vector component.

mephisto

22-04-2011 17:02:41

NxOgre::Matrix44 mat44;
NxOgre::Vec3 vec3( 0, 10, 0 );

mat44 = vec3;
mat44.set( vec3 );

why the last two lines have different results.
When I create body with "mat44.set" the orientation is not set to IDENTITY ?

mephisto

22-04-2011 20:33:49

template<typename T> T translation_as() const // Matrix44 class
{
T t;
t.x = m.m[0][3];
t.y = m.m[1][3];
t.z = m.m[2][3];
}
'NxOgre::Matrix44::translation_as<Ogre::Vector3>' : must return a value
I suppose it should return "t";

betajaen

22-04-2011 21:04:02

Yep. :D

Visual Studio should really report these as errors, rather than skipping over them.