Forums Archive Home » NxOgre

NxOgre 0.9-38.SVN-NxOgre 0.9'39 information;5 new features!

betajaen

27-07-2007 11:57:22

Latest Version

NxOgre 0.9'37 Release Notes

Download for Visual Studio, Windows, Eihort, PhysX 2.7.2

1. Install TortoiseSVN.
2. Go to your Ogre library folder (c:/dev/)
3. New Folder, name as NxOgre
4. File, SVN, SVN Checkout
5. Change the URL to "http://latest.nxogre.org/nxogre3/";
6. Click okay
7. Open up the project and compile.

_______________________________________

Optional dependencies for the JSON serialiser.

http://get.nxogre.org/dependencies.zip

Follow the instructions in the file "DependenciesReadme.txt" to install and use.

_______________________________________

See the previous release thread for full changes, pictures and so on.

betajaen

27-07-2007 12:07:27

Betajaen's very quick guide to serialization!

The Serialization system works with four formats: XML, Binary, COLLADA and JSON.

XML and Binary are the best formats to work with NxOgre. "UserProperties" which are exported with the Scene contain some bits to make it all work such as SceneNode hierarchy, Meshes used and Actor types. Only XML, Binary and JSON support UserProperties.

COLLADA is more suited as an export format from 3D modellers such as Maya or 3DS Max (which there are PhysX exporters available).

JSON is designed to work with NxOgre to NxOgre use only and supports some exporting at the moment. You'll need my copy of the jsoncpp library and to flick on a compiler flag to work with it.

You can convert between file formats, but just loading them into a scene and re-saving them. Remember to freeze the World so nothing moves!

To save a scene

mWorld->getSerialiser()->saveScene(mScene, "myScene.xml");

Format of the file is deterimined by the extension of the filename: PhysX-XML (.xml), COLLADA (.dae), Binary (.bin or .nxs) and JSON (.json)

To import a scene

mWorld->getSerialiser()->restoreScene(mSceneMgr, "myScene.xml");
mScene = mWorld->mScenes->get("mySceneName");


That's it

daedar

27-07-2007 16:04:51

Wow :shock: !

Very impressive, thx again for sharing betajaen :D

ebol

27-07-2007 18:20:31

Thanks betajaen! :D I've been waiting to see this :) Thanks for sharing.

edit:

Just tried to build the latest version, it looks like you forgot do implement method of SuperFixedSceneController class - SuperFixedSceneController::setTiming(float,unsigned int,unsigned int) to be precise.

Or this revision is not working with NX_UNSTABLE declared (not everything implemented yet)?

betajaen

27-07-2007 21:01:21

Didn't notice that! That function is for importing scenes but since PhysX doesn't know about the SuperFixedController (it only deals in Fixed and Variable) it won't use it.

It'll be fixed in '33 though.

Pottej

28-07-2007 16:08:13

Nice work Betajaen!

betajaen

30-07-2007 01:13:33

NxOgre 0.9'33

0.9-33
- Serialiser
- Serialiser Class
- Now a singleton. Use "Serialiser::functionName" to access.
- Exports and Imports a Physics World to a files or a string.
- Exporting process moved to exportWorld(...)
To a file -> void exportWorld(NxString file, ExportType);
To a string -> NxString exportWorld(ExportType);

- Importing process moved to importWorld(...)
From a file -> void importWorld(NxString file, ExportType);
From a string -> void importWorldFromString(NxString str, ExportType);
- JSON
- NxJSON namespace removed.
- Class renamed to NxJSONCollection
- Export
- Shapes #Nearly-all
- TriangleMeshes
- ConvexMeshes
- Importing
- Scene #Most
- Actors #Most
- Shapes #Most
- Materials #Nearly-All (TODO: Spring, Userproperties and flags)
- TriangleMeshes #Most (TODO: UserProperties and Flags)
- ConvexMeshes #Most (TODO: UserProperties and Flags)
- TerrainShape Mesh-Scale is now a direct scale and no longer a modifier on the imagesize.
- SuperFixedController now can be used with serialisation. However NxuStream has no concept
of a SuperFixedController so it cannot be used.
- mScenes in World is now a protected variable.
- getScenes() in World created.

<Betajaen> 30-July-2007


Since the serialiser interface has changed, here is the rundown.


Exporting to a file:
Serialiser::exportWorld("test.json", Serialiser::ET_JSON);


Exporting to a string (so it can be saved to a saved game file or streamed across a network):
NxString str = Serialiser::exportWorldToString(Serialiser::ET_JSON);

Importing from a file:
Serialiser::importWorld("test.json", Serialiser::ET_JSON, mSceneMgr);

Importing from a string:
Serialiser::importWorldFromString(str, Serialiser::ET_JSON, mSceneMgr);

All of the formats work perfectly fine, including the binary dump into strings. I'll post further code if needed.

I'll post the JSON dependency tomorrow (it'll be just the headers and lib's.). There is no extra DLL, it's statically linked into NxOgre. There is also a breakage in Cakebox with the new release, that'll be uploaded tomorrow as well.


Enjoy!

ANdys

30-07-2007 02:46:40

Amazing and soon :shock: !!
Thank your big sharing!!

betajaen

30-07-2007 09:47:21

Indeed!

The dependencies for the NxJSON serialiser are up now, so you can play around with it as well. Once the initial hump of supporting most of the serialisation of the scene, you'll find it's a nice little format for working with NxOgre to NxOgre applications over the provided Ageia ones. :D

kenny.bsp

01-08-2007 00:08:46

1>------ Build started: Project: NxOgre, Configuration: Debug Win32 ------
1>Compiling...
1>NxOgreStable.cpp
1>d:\dev\nxogre\include\nxogrestable.h(113) : warning C4005: 'NX_USE_FORCEFIELD_API' : macro redefinition
1> d:\dev\nxogre\include\nxogrestable.h(99) : see previous definition of 'NX_USE_FORCEFIELD_API'
1>Compiling...
1>NxOgreJSONWrite.cpp
1>d:\dev\nxogre\include\nxogrejson.h(27) : fatal error C1083: Cannot open include file: 'json/json.h': No such file or directory
1>NxOgreJSONRead.cpp
1>d:\dev\nxogre\include\nxogrejson.h(27) : fatal error C1083: Cannot open include file: 'json/json.h': No such file or directory
1>NxOgreJSON.cpp
1>d:\dev\nxogre\include\nxogrejson.h(27) : fatal error C1083: Cannot open include file: 'json/json.h': No such file or directory

……..
1>d:\dev\nxogre\source\nxustream2\nxu_physicsinstantiator.cpp(753) : error C2039: 'dominanceGroup' : is not a member of 'NxActorDesc'
1> d:\dev\physx\sdks\physics\include\nxactordesc.h(260) : see declaration of 'NxActorDesc'
1>NXU_PhysicsExport.cpp
……..
1>NXU_cooking.cpp
1>Generating Code...
1>Compiling...
……..
1>NxOgreSerialiser.cpp
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C2146: syntax error : missing ';' before identifier 'dominanceGroup'
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note: ……..

1>d:\dev\nxogre\include\nxogreactor.h(55) : error C2146: syntax error : missing ';' before identifier 'dominanceGroup'
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>NxOgreJoint.cpp
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C2146: syntax error : missing ';' before identifier 'dominanceGroup'
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>NxOgreMotor.cpp
1>NxOgreShapeWheel.cpp
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C2146: syntax error : missing ';' before identifier 'dominanceGroup'
1>d:\dev\nxogre\include\nxogreactor.h(55) : error C4430: missing type specifier - int assumed. Note:
……..

1>d:\dev\nxogre\source\nxogreforcefield.cpp(242) : error C2039: 'createForceField' : is not a member of 'NxScene'
1> d:\dev\physx\sdks\physics\include\nxscene.h(287) : see declaration of 'NxScene'
1>d:\dev\nxogre\source\nxogreforcefield.cpp(249) : error C2039: 'releaseForceField' : is not a member of 'NxScene'
1> d:\dev\physx\sdks\physics\include\nxscene.h(287) : see declaration of 'NxScene'
1>d:\dev\nxogre\source\nxogreforcefield.cpp(296) : error C2065: 'mDescription' : undeclared identifier
1>d:\dev\nxogre\source\nxogreforcefield.cpp(296) : error C2228: left of '.setToDefault' must have class/struct/union
1> type is ''unknown-type''
1>d:\dev\nxogre\source\nxogreforcefield.cpp(297) : error C2228: left of '.pose' must have class/struct/union
1> type is ''unknown-type''
.
.
.
.
1>NxOgreDebugRenderer.cpp
1>Generating Code...
1>Build log was saved at "file://D:\dev\NxOgre\compiler\Windows\Debug\BuildLog.htm"
1>NxOgre - 167 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

It's a 6 page log, so I removed some of it :D
I know about JSON dependences don't think about it as an error.

betajaen

01-08-2007 09:08:40

Set the flag NX_USE_JSON to 0 in NxOgreStable.h and what PhysX version are you using?

kenny.bsp

01-08-2007 16:04:20

Redownloading sdk solved the problem
the one I installed before was corrupt :D

danharibo

01-08-2007 21:28:30

Is it possible to rotate a wheel 90 degrees so the steering applied acts the opposite way it should?

betajaen

01-08-2007 21:42:55

I expect so but the wheel would face in the opposite direction and go backwards when you want forward. Can't you just invert the steering angle?

danharibo

01-08-2007 21:49:47

I expect so but the wheel would face in the opposite direction and go backwards when you want forward. Can't you just invert the steering angle?not without creating more variables, and i tried setting the steering angle to 180 but it didn't work.

betajaen

01-08-2007 21:51:21

Only one.

bool oppositeTurn;
...
if (oppositeTurn)
mWheel->turn(-angle);
else
mWheel->turn(angle);

danharibo

01-08-2007 22:10:15

Only one.

bool oppositeTurn;
...
if (oppositeTurn)
mWheel->turn(-angle);
else
mWheel->turn(angle);
Thanks for cleaning that up, i got it now

danharibo

02-08-2007 21:37:01

betajaen, you have probably played suf, and is there a way to get the wheels turning smother? as the tractors keep falling over at the moment :P

betajaen

02-08-2007 21:52:07

Smoother? You could try lowering the center of mass of the tractor, it'll make it more stable during turns, also turning less sharply will help as well.

danharibo

02-08-2007 22:00:09

Smoother? You could try lowering the center of mass of the tractor, it'll make it more stable during turns, also turning less sharply will help as well.thanks, i'm working on the turning now, but didn't know the CoM would be so important, it was already quite low.

plucked

03-08-2007 15:07:40

Hello,

I've problems with compiling NxOgre. What I've done:

0. Install latest OgreSDK and load via SVN the OgreNew Folder
1. Install latest Agaia Driver and SDK 2.7.2
2. Set the Environment-Path for PHYSX_DIR
3. Download via SVN NxOgre
4. Set the env path for NXOgre

I think that are all requirements.

When I compile I get errors on line 55 in NxOgreActor.h

" NxDominanceGroup dominanceGroup;"

When I click on NxDominanceGroup and go to definition, he found it. Where is my problem?


First lines of the compiler Errors (in German, I've no other compiler here )o: ):


1>------ Erstellen gestartet: Projekt: NxOgre, Konfiguration: Debug Win32 ------
1>Kompilieren...
1>NxOgreJSONWrite.cpp
1>c:\nxogre\nxogre\include\nxogreactor.h(55) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'dominanceGroup'
1>c:\nxogre\nxogre\include\nxogreactor.h(55) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
1>c:\nxogre\nxogre\include\nxogreactor.h(55) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
1>c:\nxogre\nxogre\source\nxogrejsonwrite.cpp(202) : warning C4800: 'NX_BOOL': Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
1>c:\nxogre\nxogre\source\nxogrejsonwrite.cpp(205) : warning C4800: 'NX_BOOL': Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)
1>NxOgreJSONRead.cpp
1>c:\nxogre\nxogre\include\nxogreactor.h(55) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'dominanceGroup'
1>c:\nxogre\nxogre\include\nxogreactor.h(55) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
1>c:\nxogre\nxogre\include\nxogreactor.h(55) : error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis: "default-int" wird von C++ nicht unterstützt.
.
.
.

betajaen

03-08-2007 15:29:26

Are you sure PHYSX_DIR is pointing to your 2.7.2 install? Dominance Groups are a 2.7.2 feature

plucked

03-08-2007 15:44:33

Yes and I found this definition when I follow it via "go to definition".

I uninstall all Agaia Drivers and SDKs, delete the rest and reinstall the driver and the sdk.

danharibo

07-08-2007 21:09:47

Betajean, How can i make my Vehicles "Heavier", the mass on the tractors is already quite high, but they like to slide about. D:

betajaen

07-08-2007 21:27:36

You could try adding some damping.

danharibo

08-08-2007 14:23:47

You could try adding some damping.That's better, i don't know what i would do without you :P

betajaen

08-08-2007 14:49:32

Cry into a pillow, call it quits, and join a travelling Welsh circus?

danharibo

08-08-2007 15:05:11

Cry into a pillow, call it quits, and join a travelling Welsh circus? :lol: Or I'd go back to Newton. it's not the fastest of Physics Engines.

betajaen

08-08-2007 15:28:49

You won't even consider joining the circus?

danharibo

08-08-2007 15:46:29

You won't even consider joining the circus?Nah, I'm too much of a coder to do anything like that :P

danharibo

09-08-2007 17:06:43

------ Build started: Project: NxOgre, Configuration: Debug Win32 ------
Compiling...
NxOgreStable.cpp
c:\programing\newnxogre\nxogre\include\nxogrestable.h(59) : fatal error C1083: Cannot open include file: 'nxversionnumber.h': No such file or directory
Build log was saved at "file://C:\programing\NewNxOgre\NxOgre\compiler\Windows\Debug\BuildLog.htm"
NxOgre - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
:x WHY!!!

Nevermind I broke an Environment Variable.

Virion

12-08-2007 14:17:01

i also got the same problem. how you solve the problem?

betajaen

12-08-2007 14:18:49

Dan fixed it with setting the PHYSX_DIR environmental variable to the correct PhysX directory, did you?

Virion

12-08-2007 14:22:52

My PHYSX_DIR is
C:\Program Files\AGEIA Technologies\SDK\v2.7.2

Edit: Still the same...

Virion

12-08-2007 14:30:37

The compiling error is exactly the same with dan's

------ Build started: Project: NxOgre, Configuration: Debug Win32 ------
Compiling...
NxOgreStable.cpp
c:\ogresdk\nxogre\include\nxogrestable.h(59) : fatal error C1083: Cannot open include file: 'nxversionnumber.h': No such file or directory
Build log was saved at "file://C:\OgreSDK\NxOgre\compiler\Windows\Debug\BuildLog.htm"
NxOgre - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


So I wanna know what he put as his PHYSX_DIR. thx, the reply is very fast. :D

betajaen

12-08-2007 14:51:21

As long as the directories "Bin, Graphics, LowLevel, Samples, SDKs, Tools and TrainingPrograms" are inside it's fine.

Did you restart Visual Studio or you computer when you added/changed the environmental variable, sometimes this is needed it for it to be noticed.

plucked

12-08-2007 16:10:45

I solve my compiling problem by coping all headers from the ageia sdk into the includefolder of the nxogre source. Its ugly, but it was the only way which work.

jchmack

13-08-2007 09:53:24

getting this link error:

1>Linking...
1>LINK : fatal error LNK1181: cannot open input file 'jsoncpp.lib'

i have this defined too
#define NX_USE_JSON 0

should i just download JSON?

edit: Bah i'm an idiot... for any other idiots out there just remove it in linker properties

betajaen

13-08-2007 10:57:32

I know, I left it in by accident. Do'h.

danharibo

13-08-2007 14:16:16

betajaen, is it possible to get version 29 of NxOgre? as the SVN is missing the shape description headers for that version.

betajaen

13-08-2007 14:25:32

Should be able to, I remember seeing an option in TortoiseSVN to specify a version number and not the head version.

But ShapeDescription was renamed to ShapeBlueprint in later versions. Perhaps your getting confused with that?

danharibo

13-08-2007 14:38:25

Should be able to, I remember seeing an option in TortoiseSVN to specify a version number and not the head version.

But ShapeDescription was renamed to ShapeBlueprint in later versions. Perhaps your getting confused with that?when i try to build r29, i get errors about ShapeDescription*.h not found. But it worked before :(

betajaen

13-08-2007 14:52:26

Can't you use '33?

danharibo

13-08-2007 14:55:13

Can't you use '33?Not until Ageia make smaller Drivers distribs.

betajaen

13-08-2007 15:24:58

If your talking about PhysX 2.7.2, you can use 2.7.0 with '33.

Aiursrage2k

13-08-2007 15:27:07

In case anyone is still compiling with visual studio 2003.


Modify the solution and script to 2003 using a text editor. Version 8.00 and Version="7.10" respectively

->The only thing you need in the source is f_opens to fopen.
->In release mode of the solution it will give an error. You will need to change the general option: 'optimize whole program' to No
->Make sure to update your DLLs to your working directory.

danharibo

13-08-2007 16:41:48

how do i make NxOgre 33 use Physx 2.7.0?

betajaen

13-08-2007 16:43:58

It's automatic. Theoretically it should not compile any of 2.7.2 features for you.

danharibo

13-08-2007 16:51:02

NxOgre - 163 error(s), 1 warning(s)

About "Dominance Groups", Which is part of 2.7.2

betajaen

13-08-2007 16:59:19

You can comment those bits out then, or better still surround them with:

#if NX_SDK_VERSION_NUMBER >= 272
xxx
#endif

danharibo

13-08-2007 18:02:56

You can comment those bits out then, or better still surround them with:

#if NX_SDK_VERSION_NUMBER >= 272
xxx
#endif
Kudos, have some babies :P

papitorico

21-08-2007 17:27:26

i'm not using JASON

I have already disabled NX_USE_JSON macro,deleted dependencies from project properties, but I got the following error when compiling


Error 1 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..." NxOgre

betajaen

21-08-2007 17:35:05

Did you read the message before that, which said:

"Errors during copying process does not mean the library was built incorrectly."

betajaen

27-08-2007 11:21:45

NxOgre 0.9'34

This is regarded as an unstable version of the NxOgre. Due to some new rendering and simulating code, you may find some errors that I haven't picked up yet. Do not upgrade if you use the serialiser, as it's code has been temporary removed for a new serialisation system.


For everyone else, Enjoy the new speed increases and 2.7.2 features!

0.9-34
> Actors
+ Anti-Name collision code. In the event of two actors or bodies sharing the same name, the second
actor or body will adjust it's name to prevent collisions.
example:
Body and Body1, or Actor98, Actor99, Actor100, Actor101.

+ addShape
+ Ground
+ Cube
+ Sphere
+ Capsule


> Bodies
~ A pre-existing scenenode can be passed onto Body to use, via ActorParams.
code:
"node: myNode"

~ Entities can be specified in the name argument "(entity) entityName".
code:
mSceneMgr->createEntity("myEntity", "cube.1m.mesh");
mScene->createBody("(entity) myEntity", ...);
(or)
mScene->createBody("myBodyName; (entity) myEntity", ...);

! Fixed a minor design bug with during the frame or frame after, when a Body is created there is a
moment where the SceneNode (and attached Movable Objects) is at 0,0,0 in the Scene.

> Serialisation
+ TinyXML added to optional depedencies for NxSerialiser's NxXML fileformat.
~ Serialiser changed to a namespace. Added global functions to retain interface.
~ Serialisation split into two techniques; NxuStream (XML, COLLADA and Bin) and NxSerialiser (NxXML,
JSON and NxBinary). Both serialisation techniques capabilities are based on the optional dependecies
you provide to NxOgre. See NxOgreStable.h

[Very incomplete. Use NxOgre 0.9'33 if you require the serialiser]


> Blueprints
+ Blueprints namespace set up, for an intermeditary serialised system for NxSerialiser. Blueprints
can be quickly be used to store the current Physics Scene in memory somewhere and quickly unpack
it again, or even be used for your own serialisation system.
> Blueprint classes
+ World
+ Scene
+ Actor

> Shapes
~ Simplified and standardised ShapeParams to NxShapeDescription code.
+ Shape to ShapeBlueprint functions written.
+ CompoundShape (ShapeGroup in 0.6) created.
code:
new CompoundShape(new CubeShape(1), new SphereShape(0.5, "offset: 0 1 0"))

+ moveToActor function created
+ copyToActor function created
+ For Cube


> Params System
> ActorParams
~ Rewrote and changed variable names.
+ All of NxActorDesc and NxBodyDesc variables are represented in some form in the ActorParams.
+ Added fromNxActorDesc and fromNxBodyDesc to ActorParams
> Rewrote the ShapeParams system.
~ Rewrote and changed variable names.
+ Documentated ShapeParams in Doxygen style.

> Error System
+ All PhysX error messages and warnings are routed through the Error system. ErrorReporters
such as Log or your own ErrorReporter class can take advantage of them now.

> FixedSceneController
! Fixed a problem with the FixedSceneController advancing the state of the simulation whilst
PhysX was still calculating it. This may be the cause of Scene jittering or pauses being
experienced in previous version of NxOgre.
+ Added "Idle" function to Scene, to preform idle or to do some future events whilst the PhysX
iterator is calculating the next frame.

> Summary struct and related functions.
~ Removed.

> Triggers
+ Now handles Character events (OnEnter, OnLeave and OnInside)

> Ogre 1.5 'Shoggoth'
! Added a precompiler if/else for getFrameNumber/getNextFrameNumber interface change between
Shoggoth and Eihort.

> Testing
+ Test Class implemented
+ TestCase based class implemented
+ Test Cases
+ SDKCore Test Case created : Tests the SDK by creating 63 Scenes at once and deleting them.
+ RigidActors Test case created : Tests Eight Scenes with 128 Actors by simulating/rendering for a second each.

> DominanceGroups
+ Implemented Dominance Groups
+ Added related DominanceGroup methods to Scene.

> Scenes
+ Added support for StaticGeometry for Static actors with visualisations (Bodies, etc.)

> Changes.txt
+ Added new system to tell what is a Bugfix (!), a Change (~) or an addition (+).

<Betajaen> 25-August-2007



> Raycasters
+ Can now raycast against Characters

<WolverinePL> 22-August-2007 http://www.ogre3d.org/phpBB2addons/viewtopic.php?p=29499#29499
<Betajaen> Implemented and slighty rewritten. 22-August-2007

betajaen

27-08-2007 11:39:34

How to use DominanceGroups

Let's make Spheres less Dominance to Cubes, so a oneway collision occurs in favour of Cubes.

mScene->createDominanceGroup("Spheres");
mScene->createDominanceGroup("Cubes");

// Make Cubes more Dominant than Spheres (1 > 0)
mScene->setDominanceGroupPair("Cubes", "Spheres", 1.0f, 0.0f);

for (int i=0;i < 4;i++)
mScene->createBody("Sphere; sphere.50cm.mesh", new SphereShape(0.5f), Vector3(2,0.5 + i,0), "mass: 10, dominancegroup: Spheres");

for (int i=0;i < 40;i++)
mScene->createBody("Cube; cube.1m.mesh", new CubeShape(1.0f), Vector3(2,0.5 + i,0), "mass: 10, dominancegroups: Cubes");



How to duplicate an Actor
Actor* mActor2 = mActor->duplicate("myActor2", a->getGlobalPosition() + Vector3(0, 1, 0));

How to duplicate that Actor many times using an ActorBlueprint.
Blueprints::ActorBlueprint* bp = new Blueprints::ActorBlueprint();
bp->serialise(mActor, mScene);

for (int i=0;i < 16;i++) {
Actor* b = bp->unserialise("Cube", mScene);
b->setGlobalPosition(Ogre::Vector3(5, i, 5));
}
delete bp;


NxOgre will notice a name already in use, and change it so it's near to the original name; Cube to Cube1 or Sphere58 to Sphere59. Don't make a habit of it though, the algorithm to do this is slower than "StringConverter::toString(i)".

How to use the new Testing Class, for testing the SDK, NxOgre or just bench marking.

NxOgre::Test* mTest = new NxOgre::Test(mWorld, mSceneMgr);
mTest->addTestCases();
mTest->startTesting();
mTest->stopTesting();
mTest->saveToLog();
delete mTest;

How to set up a name of a body, and specify an meshname
mScene->createBody("myBodyName; meshName.mesh", ...);

How to set up a name of a body, and specify a name of a entity to use

Ogre::Entity* e = mSceneMgr->createEntity(...);
mScene->createBody("myBodyName; (entity) myEntityName", ...);

How to make all static bodies use static geometry

Ogre::StaticGeometry* sg = mSceneMgr->createStaticGeometry(...);
mScene->setStaticGeometry(sg);
// Load in bodies and make them static
mScene->createBody(... , "static: yes");
mScene->createBody(... , "static: yes");
mScene->createBody(... , "static: yes");
// And build the StaticGeometry for use.
sg->build();


Triggers now work with Characters
class myTrigger : public TriggerCallback::InheritedCallback {

public:

void onEnter(Trigger*, Actor* a) {
}

void onLeave(Trigger*, Actor* a) {
}

void onInside(Trigger*, Actor* a) {
}

void onEnter(Trigger*, Character* a) {
}

void onLeave(Trigger*, Character* a) {
}

void onInside(Trigger*, Character* a) {
}
};

kenny.bsp

27-08-2007 11:50:04

> FixedSceneController
! Fixed a problem with the FixedSceneController advancing the state of the simulation whilst
PhysX was still calculating it. This may be the cause of Scene jittering or pauses being
experienced in previous version of NxOgre.
I still have jittering, unless I simulate every frame manually

betajaen

27-08-2007 12:23:33

Jittering with what?

jchmack

27-08-2007 12:38:25


This is regarded as an unstable version of the NxOgre. Due to some new rendering and simulating code, you may find some errors that I haven't picked up yet. Do not upgrade if you use the serialiser, as it's code has been temporary removed for a new serialisation system.


From what i am seeing now it looks and feels a lot more stable than 0.9-33. I used to have many crashes when dealing with massive amounts of actors and deleting them. I don't really see any jittering like kenny.bsp is talking about. But i think i had similar problems when i upgraded to 0.9-33 and my solution was changing the fixed timestep. Looking really nice so far. I recommend upgrading for a lot of the speed features alone. Not to mention stability (for me at least). Keep up the good work beta =).

edit: by the way beta is this 0.9-34 the same as the one you pmed me with? Should i upgrade again?

daedar

27-08-2007 12:40:24

wow! nice changelog :shock:

I've just a little problem with StaticGeometry, it seems that I can't scale meshes when using it, here's my code:


StaticGeometry* sg = mSceneMgr->createStaticGeometry("AdocStaticGeometry");
PhysicEngine::getSingleton()->getNxScene()->setStaticGeometry(sg);

...

NxOgre::TriangleMeshShape *mShape = new NxOgre::TriangleMeshShape(nxsFilename, "mesh-scale: "+StringConverter::toString(pObjNode->getScale()));
NxOgre::Body *body = PhysicEngine::getSingleton()->getNxScene()->createBody(string(pszFileName), mShape, pObjNode->getPosition(), "static: yes, Group: ObjectsGroup");
body->setGlobalOrientation( pObjNode->getOrientation() );
body->getNode()->setScale( pObjNode->getScale() );
body->getNode()->setOrientation( pObjNode->getOrientation() );

...

sg->build();


and my meshes aren't scaled at all :( (works fine without the 3 lines used for SG)

One last thing, I was just wondering if we can share Shapes between bodies... I've got a lot of static objects in my scene and some of them have the same mesh, then the same TriangleMeshShape. I should be nice (for loading time and memory) to be able to use the same TriangleMeshShape for multiple objects. (I've tried and it doesn't seems to work fine)

Thx :D

betajaen

27-08-2007 13:36:09

edit: by the way beta is this 0.9-34 the same as the one you pmed me with? Should i upgrade again?

It's based on it. It has DominanceGroups, StaticGeometry and that NxUserData thing in Character. It's worth upgrading.

I've just a little problem with StaticGeometry, it seems that I can't scale meshes when using it

I didn't try out the scaling in StaticGeometry. To be honest it was a rush job that I did in 10 minutes. I'll see if I can fix it.


One last thing, I was just wondering if we can share Shapes between bodies.

In the future you'll be able to share meshes (triangle/convex/skeleton/terrain) but not shapes. It won't matter to much, meshes have a bigger footprint in memory than shape.

Caphalor

27-08-2007 13:47:26

I'm very happy that the custom naming of bodies (especially the entities) is no "official supported", I implemented an accordant constructor some weeks ago but without using the cool parameter system :D
Do you know when there will be the possibility to adjust the joint params (spring, twist)? I don't want to change something myself and then there is a thousand times better solution available in a week. ;)

betajaen

27-08-2007 14:08:44

The Joint system is on my TODO list. I'm hoping I have that done (or most of it) and the mesh manager in the next release.

daedar

27-08-2007 15:38:46

Since .34, my applicaiton is crashing in the render method, more precisely here (NxOgreScene.cpp:852):


NxActorUserData* aud;
for(NxU32 i = 0; i < nbActors; ++i) {

# if (NX_USE_CHARACTER_API == 1)

aud = static_cast<NxActorUserData*>(actors[i].userData);

switch (aud->getType()) {
case NxActorUserData::T_Actor:
aud->toActor()->render(time);
break;

case NxActorUserData::T_Character:
aud->toCharacter()->render(time);
break;
}
# else
aud->toActor()->render(time);

# endif


Also, what about aud if we're not using NX_USE_CHARACTER_API? it seems to be always NULL :(

Night Elf

27-08-2007 16:13:10

I'm getting these error when I try to compile:

Error 3 error C2027: use of undefined type 'NxOgre::Serialiser::NxSerialiser::Serialiser' c:\Libs\NxOgre\NxOgre\source\NxOgreSerialiser.cpp 130
Error 4 error C2227: left of '->importBinaryFromFile' must point to class/struct/union/generic type c:\Libs\NxOgre\NxOgre\source\NxOgreSerialiser.cpp 130

The only difference is I'm setting #define NX_USE_JSON 0 to avoid the dependency.

betajaen

27-08-2007 16:14:54

@daedar
Line 852 is "case NxActorUserData::T_Actor:" for me. That won't cause any errors. What is line 852 for you, the "aud->toActor()->render(time)"?

Are you using any weird combination of NxOgre, have you created any PhysX actors directly or been messing around with any NxUserData?

Yes, your right about aud and fixed.

@NightElf, with a red lizard as an avatar. Not very Elfish

Try deleting the NxOgre directory and re-download the SVN, it may be a stray file from an old version.

daedar

27-08-2007 16:20:20

yes, the line in question is aud->toActor()->render(time).In fact this occurs when I delete an actor between the simulate method and the render one.

I've got my own listener so I call simulate at the begining of the frameStarted, I delete actors somewhere after (always in the frameStarted method) and I call render in the frameEnded method.

It works fine when I delete my actors before simulate or after render...

betajaen

27-08-2007 16:42:41

Okay. I got the same error as you with the same setup with Cake. It's to do with one of those actors which you've deleted being given to the render method saying it has moved (which it has) but was deleted straight after.

Night Elf

27-08-2007 16:47:28

Apparently, my problem was that I was setting #define NX_USE_JSON 0. After setting it to 1, it seems to build just fine and doesn't complain about JSONCPP missing... (as did revision 33)

betajaen

27-08-2007 16:56:01

Ahh. Makes more sense. I realised I left the flag on, when I updated the SVN, and I expected errors popping up like yours. ;)

daedar

Try this:
NxActorUserData* aud;
for(NxU32 i = 0; i < nbActors; ++i) {

if (actors[i].actor == 0)
continue;

aud = static_cast<NxActorUserData*>(actors[i].userData);

# if (NX_USE_CHARACTER_API == 1)

switch (aud->getType()) {
case NxActorUserData::T_Actor:
aud->toActor()->render(time);
break;

case NxActorUserData::T_Character:
aud->toCharacter()->render(time);
break;
}
# else
aud->toActor()->render(time);

# endif

ANdys

27-08-2007 20:21:04

I test the trigger "on Character enter,leave,inside",but it couldn't be work!!
I try to see void SceneTriggerController::onTrigger(NxShape& ts, NxShape& as, NxTriggerFlag tf) and check the NxShape& as ,it just couldn't get any Character. Is probram from physx? :?

betajaen

27-08-2007 20:39:25

What PhysX version are you using?

ANdys

28-08-2007 02:42:18

I know what's happen = =.
I forget i turn off the character collision.
that's my probram , and Thank you :oops:

kungfoomasta

28-08-2007 05:37:32

I have the same problem that Night Elf describes. The fix is to set the JSON to 1, even if I removed the lib dependency and include paths.. lol.

Phwoar

28-08-2007 10:42:26

I had the same problem as kungfoomasta and Night Elf.

First compile complained of missing jsoncpp.lib.. I changed the define for NX_USE_JSON to 0, and got the error relating to the undefined serialiser. I changed NX_USE_JSON back to 1 and removed the link to jsoncpp.lib and it compiled properly.

betajaen

28-08-2007 10:57:35

I found out the problem for that...Delete lines 26/28 in NxOgreSerialiser.cpp, you can turn of NX_USE_JSON then. But you still have to remove the json.lib dependency in the project settings.

ebol

28-08-2007 23:57:18

Nice to see another revision, thanks :) But what happened to the debug renderer? Did anyone noticed? It doesn't behave as it did before. Take a look (thumbnail):



This scene consists of static actor aka fakefloor, a body - 1m radius sphere and a capsule type character. As you can see, only character is "debug rendered".

betajaen

29-08-2007 00:17:20

The Debug Render is really bad. I should take that code out.

Phwoar

29-08-2007 08:14:30

I found out the problem for that...Delete lines 26/28 in NxOgreSerialiser.cpp, you can turn of NX_USE_JSON then. But you still have to remove the json.lib dependency in the project settings.You're a champion. Nice to see quick responses and a well-supported project.

KUTGW!

luis

29-08-2007 08:31:59

I found out the problem for that...Delete lines 26/28 in NxOgreSerialiser.cpp, you can turn of NX_USE_JSON then. But you still have to remove the json.lib dependency in the project settings.

hmm... I see two solutions to this problem:
1- create one solution/.vcproj for each configuration (one with and one without that JSON)
2- create different build configurations in the same .vcproj and define NX_USE_JSON *in* the build configuration (not in a header) plus any other option that needs a speciall compiler/linker setup in that build configuration.

The second is the more common and the best solution... (under linux is the same concept, you just need to put a label in the makefile and use the /DNX_USE_JSON flag in the compiler).

The Debug Render is really bad. I should take that code out.

I think the debug render is a really usefull thing to have ! specially if you need to see if the collision model is aligned with the visual model.....

betajaen

29-08-2007 09:24:28

It's only temporary Luis, the new serialiser is half written, and I forgot to leave it in.

You'll probably faint to hear that the serialiser has THREE optional dependencies, based upon which file formats and serialisation engine you want to work with.

TMT

30-08-2007 05:40:07

I recommend upgrading for a lot of the speed features alone.
I have a kind of worm in Cake, 1000 spheres and 999 spherical joints connecting them and I cannot confirm that it's faster in rev 34. The mouse is nearly impossible to use with in rev 34. The mouse is okay while my giant worm is falling to the ground (it's created in the air), but once it lands, I just can barely use the mouse. I switch back to rev 33 and all is okay.

This may be an issue with Cake itself and mouse handling. But I see that with rev 33 I have 30% CPU left, but with rev 34 I have 0% CPU left. So I assume rev 34 is more efficient and making better use of the CPU, but at the expense of the user input.

plucked

30-08-2007 09:50:10

Hi,

I've a problem with the latest version from the svn:

PhysX Error (NXE_DB_WARNING) 'createActor: Dynamic triangle mesh instantiated!' in line 1108 of g:\scm\release\PhysX_2.7.2\novodex\SDKs\Physics\src\Actor.cpp

betajaen

30-08-2007 10:53:45

@TMT

That's really odd. In reality it should be the other way around. Are you in Release or Debug mode?

@plucked

Your using a TriangleMesh shape in a dynamic actor, which you should never do.

TMT

30-08-2007 13:28:32

I'm compiling Release.

betajaen

30-08-2007 13:44:41

Try a different SceneController:

mWorld->createScene("Main", mSceneMgr, "gravity: yes, floor: yes, time-step-method: variable");

But to be fair that's 1000 bodies, with a 1000 joints, and they are all in seperate nodes and not connected. There is bound to be some frame loss.

I'm puzzled why there is such as difference between versions of NxOgre though.

frier

02-09-2007 13:16:08

Im having troubles with loading in my cake scene back into cake for testing :)..

When i write the jcon file, and read it back in the scaling ive done on a cube does not work, probably the way i'm scaling.


NxOgre::Body *ramp = mScene->createBody("cube.1m.mesh",new CubeShape(10,1,10),NxOgre::Pose(Ogre::Vector3(10,0,10),(Ogre::Quaternion(Degree(20),Ogre::Vector3(-1,0,0)))),"static: yes, group: world");

ramp->getNode()->scale(Vector3(10,1,10));

And neither do my wheels for my car which are of NxOgre::WheelSet. So the car just falls over when i load it. Anyway to fix this?

Thanks,

- FrieR

betajaen

02-09-2007 14:20:54

Not really. Serialisation is very new to NxOgre.

frier

02-09-2007 14:47:44

Yeah thats no worries. ill just import the car and stuff manually.

Ill scale manually to? its not really hard to do.. just have to make sure my artist exports at the correct size.

gugus

03-09-2007 08:11:41

Hello guys.I am realy waiting for NxOgre 1.0(i am still using 4.0 and i am a "beginer").
So i would be very happy if i could know when NxOgre 1.0 will be release and whats missing in NxOgre 9.34(compared with NxOgre 1.0).

betajaen

03-09-2007 09:39:53

November.

Can't you use 0.9 now?

gugus

03-09-2007 20:22:04

thank for replying so quick.I would have prefere not to use SVN versions(i don't realy like to recompile it each time a new version is up) but if it release only on november i will use it.

betajaen

03-09-2007 20:37:39

With an average of one and half releases a month, I think you'll be okay.

gugus

04-09-2007 10:48:39

i am having trouble to compile NxOgre:

------ Début de la génération : Projet : NxOgre, Configuration : Debug Win32 ------
Compilation en cours...
NxOgreStable.cpp
c:\ogresdk\nxogre\nxogre\include\nxogrestable.h(142) : warning C4005: 'NX_USE_FORCEFIELD_API' : redéfinition de macro
c:\ogresdk\nxogre\nxogre\include\nxogrestable.h(135) : voir la définition précédente de 'NX_USE_FORCEFIELD_API'
Compilation en cours...
NxOgreTesting.cpp
NXU_tinyxmlparser.cpp


Killed by Betajaen. Not everyone needs to see that.

ebol

04-09-2007 10:57:03

What PhysX SDK version are you using? It seems your using some older version - currently nxogre works bests with 2.7.2 SDK

betajaen

04-09-2007 11:03:44

That's version 2.6.x at least there. Use PhysX 2.7.2

gugus

04-09-2007 11:04:31

i just edit my message.I forgot to change the environemental variable.I had now (only?) 364 errors instead of 1015...
I don't understand why he can't find NxPhysique...

gugus

04-09-2007 11:12:21

I still have this error:

c:\ogresdk\nxogre\nxogre\include\nxogrestable.h(87) : fatal error C1083: Impossible d'ouvrir le fichier include : 'NxVersionNumber.h' : No such file or directory

EDIT:i just restarted visual studio and its OK now.

ebol

04-09-2007 11:18:08

Did you reboot your PC after changing environmental variable? If not, do so.

CaseyB

04-09-2007 17:17:21

You shouldn't need to reboot, you will need to restart Visual Studio however, which it looks like it solved the issue for him.

ANdys

05-09-2007 10:02:39

How to create a Simple ForceField and using ForceFieldParams?

Thanks!! :)

plucked

05-09-2007 11:38:11


@plucked

Your using a TriangleMesh shape in a dynamic actor, which you should never do.

Hmmm what could I use for a static building?

My code is:

NxOgre::Body* myCube = nxScene->createBody(
"qaa.mesh",
new NxOgre::TriangleMeshShape( "qaa.mesh"),
NxOgre::Pose(
Ogre::Vector3(0,0.001,0),
Ogre::Quaternion(Ogre::Radian(Ogre::Degree(45)),Ogre::Vector3::UNIT_Y)
),
"static: yes"
);

Is this the right way?

betajaen

05-09-2007 12:12:16

yep.

gugus

05-09-2007 16:21:38

I have a few question.When i create a World with the option Framelistener : Yes,how does it find Ogre::Root to create a new frameslistener?And if i put Framelistener : NO,how does it work?

betajaen

05-09-2007 16:35:32

1. Root is a singleton. It isn't hard to get the pointer from that.

2. To work without a frame listener, you must inject render and simulate by hand.

mWorld->getPhysXDriver()->simulate(deltaTime);
mWorld->getPhysXDriver()->render(deltaTime);

Both of those must be called like that. You can't do two simulates then a render, or two renders and no simulates.

gugus

05-09-2007 16:57:50

I forgot that Root was a singleton :oops: :oops:

that's a cool new feature not to need the framelistener!But what is render doing?Is it rendering the scene with ogre?In that case , the physiqual simulation is still dependant from FPS...

betajaen

05-09-2007 16:59:07

Render set's the pose of all of the moved scene nodes, updates any cloth/softbodies, etc.

gugus

05-09-2007 19:51:47

ok thanks

betajaen

06-09-2007 15:13:50

NxOgre 0.9'35

0.9-35
> Actor/Bodies
! Fixed a typo with setAngularDamping.
~ Unified the identifier generation system.
+ Inherited Actors (other than body) can make use of the "name; visualData" system, using the
new mVisualIdentifier variable from Actor.
+ Added an override for the identifier generation, with a name prefixed with ">", NxOgre will
not generate a new one, it'll will also treat the identifer exactly as you want it and will
not trim any strings. In the case of two actors having the same name a crash is certain.
Use this function wisely.
code:
mScene->createActor(">myBodyName", ...);
mScene->createBody(">myBodyName; myMesh.mesh", ...);
+ Added "mBirthFrame" variable. The frame that the actor was created on.

> Joints System
- Destroyed old Joints system.
+ Prototyped new Joint System
+ JointParams
+ Revolute Joint
+ Spherical Joint

> Batching
+ Prototyped and implemented some batching code for Scene
+ added batchCreateActors
+ Support for create now
+ Support for create next frame
+ added batchCreateBodies
+ Support for create now
+ Support for create next frame

code/example:

mScene->batchCreateBodies(
"YellowCube",
"cube.1m.mesh",
32,
new CubeShape(1.0f),
Vector3(0,0.5f,0),
Vector3(0,1,0),
Scene::BT_NEXT_SIMULATION,
"mass: 10"
);

> Scene
+ added "getActorsFromBirthFrame()"
+ added "getActorsFromIdentifier()"
+ added "getActorsFromRegion()"
Returns a list of Actors in a specific region in the Scene. (A mini-intersection helper)
example/code:
Actors actors = mScene->getActorsFromRegion(new SimpleBox(Vector3(2,2,2), Vector3(8,1,0)), NX_ALL_SHAPES);

+ added "getActorsFromLastRegion()"
Preforms another intersection test based of the setup of the previous region checking.

example/code:
mScene->getActorsFromLastRegion(NX_ALL_SHAPES);

+ added "getActorsFromRayCast()"
example/code:

Actors actors = mScene->getActorsFromRaycast(origin, direction, range);

> Intersections
+ Added Intersection class
An "Intersection" returns a list of Actors within a specific portion of a scene.

+ Added support for SimpleBox
+ Added support for SimpleSphere [Untested]

code:
Intersection* intersection = new Intersection(mScene, new SimpleBox(2), NX_ALL_SHAPES);
for (Actor* actor = intersection->begin();actor = intersection->next();) {
std::cout << actor->getName() << std::endl;
}
delete intersection;

+ Added SimpleIntersection class [Untested]
A Simple Intersection returns if one or more Actors exists within a specific portion of a scene.

SimpleIntersection* intersection = new SimpleIntersection(mScene, new SimpleBox(2), NX_ALL_SHAPES);
if (intersection->getResult())
std::cout << "There is something in the bathroom!" << std::endl;
delete intersection;

+ Added support for SimpleBox [Untested]
+ Added support for SimpleSphere [Untested]

+ Added CulledIntersection class
A CulledIntersection culls portions of the scene using NxPlanes and returns a list of actors.

> SimpleShape System
Unified the a second system of light-shapes classes for the lesser known features of PhysX.

+ SimplePlane
+ SimpleBox
+ SimpleSphere
+ SimpleCapsule
+ SimpleConvex

> ForceFields
~ Changed ForceField system to use SimpleShapes [Untested]

> Containers
+ Mini-Tutorial in comments on how to use the iterator interface.
+ Alternative iterator interface for non-pointer based storage; _begin(), _atEnd() and _next().

> RayCasting
+ Finished of the "RCT_ALL" raycasting code.

code:

if (mSceneRayCaster->mReport.count() > 0) {
for ( RayCastHit hit = mSceneRayCaster->mReport._begin();
!mSceneRayCaster->mReport._atEnd();
hit = mSceneRayCaster->mReport._next()
)
{
std::cout << hit.mActor->getName() << std::endl;
}
}

<Betajaen> 6-September-2007


For those who use the Joint system already, you may want to miss this one. For everyone else, enjoy the new stuff!

betajaen

07-09-2007 10:28:54

NxOgre 0.9'36

0.9-36

> Joints System
~ Added NxJoint functions to Joint
+ Prismatic
+ Cylindrical
+ Fixed

> Scene
+ Factory methods for Spherical, Cylindrical, Fixed and Prismatic Joints

TMT

07-09-2007 12:53:32

I just want to say thanks for these new revisions.

betajaen

07-09-2007 13:00:31

Thankyou. It's nice that one of the many many users of NxOgre would say thank-you now and again. ;)

betajaen

07-09-2007 13:26:11



You can't really tell in the screen shot. But all of those actors are joined together via FixedJoints. They should be very very handy for those game developers who want destructible objects; such as crates, doors, or even buildings.

As for those Cake2 wanters; I'm playing with the idea of leaving those BetaGUI windows in. ;)

ebol

07-09-2007 23:31:01

Hey, thanks for the new stuff :)

Unfortunately, I can't create SphereticalJoint (others works fine, as far as I tested). When calling:

scene->createSphericalJoint(act1,act2,pos);

no joint is created, and I got this error in nxogre log:


NxOgre::Error::reportError#78T0 F0

PhysX Error (NXE_INVALID_PARAMETER) 'NpScene::createJoint: desc.isValid() fails!' in line 917 of g:\scm\release\PhysX_2.7.2\novodex\SDKs\Physics\src\NpScene.cpp


Am I missing something :?

betajaen

08-09-2007 09:48:28

My bad, I never tested it. I just assumed it worked. Anyway it should work for you now.

0.9-37

> Joints System
~ Added default values for JointParams

> Shapes
~ Shape ID is now specified by the Actor, and not guessed.

> Helpers
+ Added Matrix3 to NxMat33 converter function [Untested]

<Betajaen> 8-September-2007

ebol

08-09-2007 12:17:23

Spotted some bugs I think - can't compile latest revision (I hope those error messages speak for them self):

Error 3 error C2660: 'NxOgre::ShapeBlueprint::_bindToNxActor' : function does not take 2 arguments c:\ogresdk\latest.nxogre.org\nxogre3\nxogre\source\nxogreactor.cpp 1009

Error 4 error C2039: 'getIndex' : is not a member of 'NxOgre::Shape' c:\ogresdk\latest.nxogre.org\nxogre3\nxogre\source\nxogreactor.cpp 1021

betajaen

08-09-2007 20:52:29

There it should compile now for you (I've compiled it three times to test it out. ;))

0.9-38

> Shapes
+ Added Shape Index
~ Changed Shape::__bindToNxActor to self-bind itself into an NxShape

> Actor
~ Bug fixed addShape
+ removeShape

<Betajaen> 8-September-2007


I wouldn't recommend anyone except myself to play with the removeShape code yet, it's rather young. :D

ebol

08-09-2007 23:55:43

There it should compile now for you (I've compiled it three times to test it out. :wink:)

Hey, I believe you ;) I'll try this out the next morning. Big thanks!

betajaen

14-09-2007 19:59:30

Something to look forward to in NxOgre 0.9'39

I've done quite a bit of new work to our beloved library, and paid attention most of the time whilst writing it. NxOgre has now a Resource System, two infact. The idea is that it can load anything it needs through this Resource System without bothering or even caring where it comes from.

The first Resource System is a normal file based one, every run of the mill one. It's quite clever; PhysX can directly work with it without any wrapping, which is useful for cooking to disk. It's the default Resource System for writing any saved meshes to, as the other Resource System is only read only.

That Resource System you may ask is Ogre. Yes, it's completely bound to it, meaning that not only using traditional files to store things in, it can utilitise the many extensions to the ogre Resource System such as zip files or even (which I haven't tried) the URL plugin. It gets even better, the Ogre Resource System uses your resources.cfg file to load in NxOgre NXS files, from directories, zips and where ever Ogre can support. As long Ogre knows about it, NxOgre will to.



The second good feature of NxOgre, is the MeshManager. It's been in the SVN for a little while now, but nothings made any use of it. Well it fully supports the Convex and Triangle Meshes. When I mean support; it loads, retrieves, stores, cooks, scales, and saves triangle and convex meshes. It'll do the same with Skeleton, Soft Body, Heightfields and Cloth too.




The third feature of NxOgre, is a new application called "Converter". It's a multi-purpose command line tool, to do a number of things; Such as create/remove/amend material aliases for height fields and triangle meshes, convert Ogre meshes into Triangle Meshes, Convexes, Soft Bodies or Cloth. It'll come within the NxOgre solution now, although it'll be incomplete when '39 is released, it's still worth using.



The fourth feature is Material Aliases. NxOgre 0.6 had a feature like this, but it was quite crude. Material Aliases allow Triangle or Terrain saved meshes (nxs files) to work across applications where the material setup is different; For example on my computer Material 2 may be assigned to Rock, where as on your computer you may have Material 2 assigned to plastic, and Rock is material 9. Material Aliases save additional data with nxs files to say that when I mean Material 2, I really mean Material 9.



The fifth feature, is more a whole of all the other new features. Working with "nxs" files. These new features and systems, allow you to work with saved PhysX meshes just as easily with Ogre ones. Not only they are faster for PhysX to work with, there is no cooking of meshes in the middle of the scene, or even in the beginning of it.

mScene->createBody("racecar; racecar.mesh", new TriangleMeshShape("racecar.nxs"), Vector3(0,10,0), "static: yes");

NxOgre::MeshManager::getInstance()->saveTriangleMesh("racecar", FileResourcePointer("media/Cooked/racecar.nxs"));


Now where are screen shots Betajaen?

Well there isn't any. I was working on this video earlier on the week. I am working on something a lot better involving a shed though.

Until NxOgre 0.9'39 which is this Sunday, laters.

Night Elf

14-09-2007 22:47:55

:shock: Wow! You've been really busy! Thanks for all your effort bringing all these great features into NxOgre. Keep 'em coming :wink:

betajaen

14-09-2007 23:01:03

Indeed. My fuel has been lately some Discworld audio books of iTunes. I bought four already, and I'm really trying to resist maxing out my credit card to by the other 20-30 others. :D

I've been commenting a ton as well; Javadoc style which Doxygen is reading them in quite nicely. I've even been working on some of the params and cleaning it up a bit. Oh, I even added colour to the Visual Debugger.

ebol

14-09-2007 23:06:14

Sweeeet :D Again - thanks :)

asafdav2

14-09-2007 23:27:34

thanks a bunch

frier

15-09-2007 01:36:41

Thank you so much betajaen!, i'm going to cook me some mesh's!

NickM

15-09-2007 09:41:31

Thanks so much yet again betajaen. :D

gugus

15-09-2007 17:40:55

:shock: :shock:
Thanks betajaen!

betajaen

15-09-2007 18:26:47

Thanks guys.

Here is a "screenshot" of Thundercake the converter utility I was talking about. It's showing the help system:

Z:\Source\NxOgre\tutorials>ThunderCake_debug.exe
ThunderCake: No command given. See "ThunderCake help" for help.


Z:\Source\NxOgre\tutorials>ThunderCake_debug.exe help
ThunderCake; Help
Use:
help alias -> Material Aliases

Z:\Source\NxOgre\tutorials>ThunderCake_debug.exe help alias
ThunderCake; Help -> Material Aliases

Description:
Material Aliases allow Triangle meshes (Ogre/NXS) or Terrain images to
work across applications where the material setup is different; For
example on my computer Material 2 may be assigned to Rock, where as on
your computer you may have Material 2 assigned to Plastic, and Rock is
material 9.Material Aliases allow you to work with nxs files to say that
when I mean Material 2, I really mean Material 9.

Commands:
create <filename> <index>=<indentifer> ... -> Create material aliases.
list <filename> -> List all Indexes paired up with a Material Identifier
add <filename> <index>=<indentifer> ... -> Add one or more aliases.
remove <filename> <indentifer> ... -> Remove one or more aliases.

Examples:
thundercake alias create Car.nxm 0=Metal 1=Glass 2=Plastic 3=Rubber 4=Paper
> Done.
thundercake alias list Car.nxm
> 0=Metal 1=Glass 2=Plastic 3=Rubber 4=Paper
thundercake alias add Car.nxm 5=Leather
> Done.
thundercake alias remove Car.nxm Paper
> Done.
thundercake alias list Car.nxm
> 0=Metal 1=Glass 2=Plastic 3=Rubber 5=Leather

It should be very people who run their artwork through some chain of exporters.

Bob

16-09-2007 11:16:50

Thanks betajaen for your great work. I' am looking forward to NxOgre 1.0 :)

betajaen

16-09-2007 16:50:47

Well I was planning to release '39 today. But with ThunderCake and Ogre giving me a hard time, I spend all of last night and this morning; figuring out a way (whilst being blindfolded) to load in a Ogre mesh without a Render System, a few thousand searches later and my answers was in the OgreXMLConverter.

This has given me little time to work on the MeshManager/ResourceSystem, and to be a little honest I want it cleaned up a bit more. Which I want a better way to handle inherited resource streams without using the "new" keyword. Perhaps a smartpointer may be needed.

Monday or Tuesday then. Probably Tuesday; Team Fortress 2 tommorow ;)

ebol

16-09-2007 17:06:13

I was kind of hopping to get my hands on the new revision today, but I think we all can wait two more days - it won't be easy tho :wink:

betajaen

16-09-2007 18:13:25

You can play the Team Fortress 2 beta instead then. :D

betajaen

16-09-2007 22:00:43

Latest heads up

Well I just tore up NxOgre (and still tearing it up; 16 errors is better than 300 an hour ago - Find and Replace is an evil tool which I overuse!).

Anyway:

- MeshManager is now called ResourceManager.

- All access to resources are controlled by a SmartPtr like template-less class class called "ResourceStreamPtr" it's pretty much exactly as the Ogre SmartPtr, except for a template and different constructor code.

But unlike the OgreSmartPtr, you can do this:

ResourceStreamPtr rs = ResourceStreamPtr("file:test.text +write");
rs->writeString("Woobles");
rs->close();

ResourceStreamPtr rs2 = ResourceStreamPtr("ogre:myMesh.mesh");
rs->readByte();
// IM IN UR MESH READING UR VERTICEZ
rs->close();


- Prototyped some functions into the ResourceSystems to give the ResourceManager a list of specific file types to load; nxs, meshes, nxm, etc.

- Still figuring out how much of this Resource System interface will be public. Obviously there will be a "loadresources: yes" param in World, but I don't want a resources.cfg.

Hmm.

Caphalor

17-09-2007 18:30:38

First thanks again for your great work, but I have some questions.
1. Since I updated to 0.9.38, the ogre standard lightening system doesn't work anymore. All materials which are enlighted by custom shaders are working. Here is a screenshot:

2. Why did you you remove the ActorParams::setToStatic function? Ok it was a very small function, but I found it useful.
3. There still isn't the possibility to choose a really custom name for a body. For my app the body, the node and the entity must have the same name. If I didn't oversigted something, there is only the possibility to choose the nodename and an existing entity, but not the name of a new entity. It would be very nice if you could implement this possibility.

betajaen

17-09-2007 18:59:07

1. I took out the normalise normals in Body. It wasn't really part of NxOgre, and I felt I was over stepping my bounds there. I suspect that's why the lighting is weird.

2. I have no idea why it went missing. I can put it back though, in the mean time, just set mass and density to 0.

3. You can have the entity and the body share the same name and the node name can be done via the params.


NxString name = "myEntity";
Entity* mEntity = mSceneMgr->createEntity(name, ...);
mScene->createBody(name + ";(entity) " + name, ...., "mass: 10, node:" + name);

Caphalor

17-09-2007 20:02:09

Thank you for the answers!
1. I took out the normalise normals in Body. It wasn't really part of NxOgre, and I felt I was over stepping my bounds there. I suspect that's why the lighting is weird.
Do you have a suggestion how I can solve my problem? Is there a way to normalise the normals direct in the .mesh files? (sorry for off-topic)

betajaen

17-09-2007 20:04:03

Yeah. There is an Ogre Mesh tool posted in the main forums which may do it, unless you want to run it through the Ogre MeshUpgrader, I think there is a normalise normals function in there.

betajaen

17-09-2007 23:29:07

Blehhh!

For the ones who are looking forward to this release, i.e. ebol. I'm afraid to say that it won't come out today, and it's unlikely that its arrive tomorrow.

Pretty much the entire mesh system of NxOgre is just missing; it's like a hole, a hole that won't compile.

I'll put it into terms of perspective of what I've done TODAY; I spent all of this morning; with prototyping and deciding on the ResourceManager functions, ResourceSystem and ResourceStream functions - for the third time this weekend.

Then the early afternoon I rewrote the MemoryWrite/MemoryReadStreams to work as ResourceStreams. Then after following Luis's advice move the FileResourceStream to use the stl::fstream instead of FILE*, then an hour later I turned it back, after finding how much a pain fstream is.

Then I spent almost 5 hours trying to figure out why on earth; Cooked TriangleMeshes to disk was having the wrong files sizes, which I traced to a missing "const" on one of the virtual functions. I'm still uncertain that the cooked meshes are wrong (comparing them to cooked meshes using the same Ogre meshes from a week ago), but with no real way to test them.

Now, I'm typing here. With Two copies of the NxOgre Solution open (my main one, and one 7 hours ago), I'm busy beavering away at filling in all the gaps. Well not anymore, I'm heading to bed, must finish reading my Discworld book!

Who said Resource Management was fun? ;)

[Edit]

To prove that I haven't been spending all day in front of Steam waiting for Team Fortress 2 to turn itself on.

ebol

18-09-2007 12:39:13

Sorry to hear that :(, but you know how it is - things that looks simple and easy at the beginning can become a real pain when you start working on them, specially if you want to do it right.

Who said Resource Management was fun? ;)
I was never my thing ;)

Maybe you really should spend a day or two with TF2 and then look at the code with fresh mind ;)

Edit:

Just one question. When I was working on my ragdoll code, I was using rev 33 until mayor part of it was finished, because I needed Debug Renderer to see if actors fit well with character. I don't want to bother you with fixing it, I know you hate it guts :), so maybe you could point me in the right direction - what is actually wrong with it? What had changed? Maybe I could fix it.

betajaen

18-09-2007 16:58:32

Indeed. I have convexes working now, but I need a better way of cleaning up things. So before I left for work I came up with a primarly class to wrap up the NxConvexDesc (and other NxXXXXMeshDescs as well); It's called ConvexMeshIntermediary.

As for DebugRenderer. Actually, I may of fixed it by accident. See if this works for you:

NxOgreActor.cpp (Yes the actor!)


void ActorParams::setToDefault() {


mDensity = 0.0f;
mActorFlags = 0;
mGroupAsIndex = 0;
mGroupAsName = "";
#if NX_SDK_VERSION_NUMBER >= 272
mDominanceGroupAsIndex = 0;
mDominanceGroupAsName = "";
#endif
#if NX_SDK_VERSION_NUMBER >= 260
mCompartment = NULL;
#endif
mMassLocalPose . id();
mMassSpaceInertia . zero();
mLinearVelocity . zero();
mAngularVelocity . zero();
mWakeUpCounter = 20.0f*0.02f;
mMass = 10.0f;
mLinearDamping = 0.0f;
mAngularDamping = 0.05f;
mMaxAngularVelocity = -1.0f;
mBodyFlags = NX_BF_VISUALIZATION;
mBodyFlags |= NX_BF_ENERGY_SLEEP_TEST;
mSleepLinearVelocity = -1.0f;
mSleepAngularVelocity = -1.0f;
mCCDMotionThreshold = 0.0f;
mSolverIterationCount = 4;
mSleepEnergyThreshold = -1.0f;
mSleepDamping = 0.0f;

mNodeScale = Ogre::Vector3(1,1,1);
mNodeName = "";
mNodeShadows = true;
mNodePose . id();
}




And I agree with your medical advice to play more TF2.

Perhaps all of us on the Ogre forums can play together (assuming they have it).

An unofficial Ogre TF2 server, we'll give that Source Engine a good kicking and show which rendering engine who's boss.

I might start up a "NxOgre" steam group to kick Havoks butt. ;)

ebol

18-09-2007 18:02:43

About the Debug Renderer, I was 99% sure that the problem has something to do with actor, because I compared the Debug Renderer code from working and not working version, and it was almost the same.

At first, when I saw your code from previous post, I noticed the small difference:

old

mBodyFlags = NX_BF_VISUALIZATION;
mBodyFlags = NX_BF_ENERGY_SLEEP_TEST;


new

mBodyFlags = NX_BF_VISUALIZATION;
mBodyFlags |= NX_BF_ENERGY_SLEEP_TEST;


I laugh and said 'so it was all about the flags all along, nothing more' :P

...but unfortunately not. Things like for example joints or joint limits are shown, but actors don't. Funny tho, because characters are drawn and they are kinematic actors if I'm not wrong...

I'll take a look at it later.

And about playing TF2, I don't own basic HL2 and I assume TF2 needs it (its steel a mod like TF1, right ?). But it was tempting ;) Perhaps others can join.

betajaen

18-09-2007 18:10:32

Try this, in NxOgreWorld.cpp, Goto the createDebugRenderer function; it's line 201 for me, replace those sdk->setParameter block with this:

sdk->setParameter(NX_VISUALIZE_WORLD_AXES, true);
sdk->setParameter(NX_VISUALIZE_BODY_AXES, true);
sdk->setParameter(NX_VISUALIZE_BODY_MASS_AXES, true);
sdk->setParameter(NX_VISUALIZE_BODY_LIN_VELOCITY, true);
sdk->setParameter(NX_VISUALIZE_BODY_ANG_VELOCITY, true);
sdk->setParameter(NX_VISUALIZE_BODY_JOINT_GROUPS, true);
sdk->setParameter(NX_VISUALIZE_JOINT_LOCAL_AXES, true);
sdk->setParameter(NX_VISUALIZE_JOINT_WORLD_AXES, true);
sdk->setParameter(NX_VISUALIZE_JOINT_LIMITS, true);
sdk->setParameter(NX_VISUALIZE_CONTACT_POINT, true);
sdk->setParameter(NX_VISUALIZE_CONTACT_NORMAL, true);
sdk->setParameter(NX_VISUALIZE_CONTACT_ERROR, true);
sdk->setParameter(NX_VISUALIZE_CONTACT_FORCE, true);
sdk->setParameter(NX_VISUALIZE_ACTOR_AXES, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_AABBS, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_SHAPES, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_AXES, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_COMPOUNDS, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_VNORMALS, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_FNORMALS, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_EDGES, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_SPHERES, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_SAP, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_STATIC, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_DYNAMIC, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_FREE, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_CCD, true);
sdk->setParameter(NX_VISUALIZE_COLLISION_SKELETONS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_EMITTERS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_POSITION, true);
sdk->setParameter(NX_VISUALIZE_FLUID_VELOCITY, true);
sdk->setParameter(NX_VISUALIZE_FLUID_KERNEL_RADIUS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_BOUNDS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_PACKETS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_MOTION_LIMIT, true);
sdk->setParameter(NX_VISUALIZE_FLUID_DYN_COLLISION, true);
sdk->setParameter(NX_VISUALIZE_FLUID_STC_COLLISION, true);
sdk->setParameter(NX_VISUALIZE_FLUID_MESH_PACKETS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_DRAINS, true);
sdk->setParameter(NX_VISUALIZE_FLUID_PACKET_DATA, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_MESH, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_COLLISIONS, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_SELFCOLLISIONS, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_WORKPACKETS, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_SLEEP, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_TEARABLE_VERTICES, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_TEARING, true);
sdk->setParameter(NX_VISUALIZE_CLOTH_ATTACHMENT, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_MESH, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_COLLISIONS, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_WORKPACKETS, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_SLEEP, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_TEARABLE_VERTICES, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_TEARING, true);
sdk->setParameter(NX_VISUALIZE_SOFTBODY_ATTACHMENT, true);



If that's to much then, have a look at the old World in NxOgre 0.6, so you can pick and choose what you want.


And no you don't need Half-Life2 for TF2, it's a standalone game. If you buy the orange box like I did, it gives you HL2, and EP1 for free anyway; Everybody wins!

ebol

18-09-2007 23:13:32

Sorry that it took my so long. I tried all kinds of setup, the ones from 0.6, even the hard-core unreadable 'everything is on' you posted- actors are still not being drawn. It doesn't matter if NX_VISUALIZE_COLLISION_SHAPES parameter is set or not. So I think we can cross of body flags and sdk paramaters...

I'll try to dig little deeper tomorrow, when I get some sleep. Thanks for help and interest so far betajaen :)

betajaen

18-09-2007 23:30:53

Any chance I can have a screen shot of your Debug Renderer setup, you can PM it to me, if you want to make it private. I've also solved the colour issue as well, but it's in '39, and unless you want me to break several hundreds of NxOgre powered programs by updating the SVN, I'll come up with a different solution. It's about 3-4 lines but I forget which.

Oh, I have convex cooking to memory working now; Finally.

Once the ResourceStreamPtr's are cleaned up a little more, and some more functions are added in, anyone can safely write and read to portions of memory using the same class (beat that Ageia!); Why they would want to do such horrid things, I don't want to know.

ResourceStreamPtr memoryStream(NxMemoryStreamIdentifier);
memoryStream->writeUChar("R");
memoryStream->rewind();
std::cout << "Hey Guys, I just wrote " << memoryStream->getUChar() << std::endl;

ebol

19-09-2007 00:13:35

Sure, I'll post this as soon as I get some sleep. Actually, I was heading to bed when I got a reply notification ;) By Debug Renderer setup do you mean what visualization parameters I'm using? Sorry, I didn't quite get it.

Oh, I have convex cooking to memory working now; Finally.

Good to hear that your making progress. All those coming up features sounds really great. You know, I doubted that you will take the day off, not until you finish some satisfying portion of the code. I understand, I do it all the time ;)

Till tomorrow then,
Cheers

betajaen

19-09-2007 08:57:35

No just a screen shot. I'm pretty sure I have shapes rendered in my applications, I'm just wondering if it does the same as yours but you can't see it.

ebol

19-09-2007 11:39:26

Hmm, ok. Here's a sample scene I used for testing - 2 characters - one of them is player, ragdoll actors, 1 actor - floor and 1 body - sphere.


betajaen

19-09-2007 11:48:17

That is a little weird. But the capsule on the first screen on the right is being drawn. Any chance the meshes are slightly bigger than the shapes?

ebol

19-09-2007 11:59:30

Yeah, its weird. And the capsule you are referring to is an character. About the meshes, no, sphere has been taken from cake and ragdoll actors are slightly bigger then the visual representation. Besides, all of that was perfectly drawn in rev 33 - I updated when this code was ready and I was adding joint to it.

betajaen

19-09-2007 12:30:01



That is what I get with the colour addition and the chunk of parameters posted above in NxOgre 0.9'39. I'm thinking Ageia may of changed the DebugRenderer somehow; There isn't anything in the SDK Documentation to suggest this, and I haven't touched the code before 38 for a long time.

ebol

19-09-2007 12:51:27

Strange, I see that its working for you... I didn't change anything important in my copy of nxogre. I'm using physX 2.7.2 for some time now, and I precisely remember, that I noticed this problem when I upgraded to .34 - I even posted that on forum then here :)

I don't know what's going on then. Maybe I'll wait and test it with incoming rev .39...

betajaen

19-09-2007 15:01:14

It don't think it fully works. The meshes in the convex work for some reason, and red bits on the cubes may be AABB boxes. Notice the spheres don't have anything.

ebol

19-09-2007 15:11:46

Your right, now I see it, I got a bit confused with all that colors ;). So this black outline that sphere on the first plane has means that its currently selected. To be honest, I didn't noticed those spheres hidden behind cubes, I though that theres only one, so I assumed that everything works. When you said ' Notice the spheres' I started looking for more.

Aiursrage2k

20-09-2007 00:24:47

Small suggestion, triangle shapes should have its mass and density set to 0.

Otherwise it will be treated as a dynamic shape (if having less than 256 verts), or if it has more it will be treated as a static shape but flagged as dynamic shape. IE if you doing a linearsweep and use the static flag you wont be able to hit it, you will need to check dynamics even though it is not.

Caphalor

20-09-2007 20:56:54

Hi betajen, is it possible that you forgot the "hardness" parameter in the joint params class? You are probably bored by such lapidary problems but nevertheless it would be nice if you could check this. :D
If you say that I am not mistaken I also could implement it myself, it would be only copy and pasting I think.

betajaen

20-09-2007 21:14:56

Please do.

If anyone wants anything minor added to NxOgre, submit a patch in here, and I'll add it in to '39. Hands off from the Convex, Triangle, Heightfield code directly though.

betajaen

21-09-2007 10:38:23

Convexes are done

Well the Convex system is finally done*. It mirrors some of the Ogre Resource system, and some parts it's very clever and easy to work with, also it's a little open and works with NxConvexMeshes directly rather than some wrapped class.

To load in a Convex mesh (without it being pre-loaded via a Resource System).

NxOgre::ResourceManager* rm = NxOgre::ResourceManager::getSingleton();


rm->loadConvexMesh("convex1", ResourceStreamPtr("file:convex1.nxs"));

mScene->batchCreateBodies("Convexes", "convex1.mesh", 32, new ConvexShape("convex1"), Vector3(3,3,3), Vector3(0,1,0), Scene::BT_NOW, "mass: 10, node-scale: 2 2 2");


To scale that convex mesh by 2:

NxConvexMesh* mesh = rm->cookConvexMesh(rm->getConvexMesh("convex1"), 2);
rm->loadConvexMesh(rm->getMeshIdentifier("convex1", NxVec3(2,2,2)), mesh);

mScene->batchCreateBodies("Convexes", "convex1.mesh", 32, new ConvexShape("convex1", "mesh-scale:2 2 2"), Vector3(3,3,3), Vector3(0,1,0), Scene::BT_NOW, "mass: 10, node-scale: 2 2 2");

Meshes that have the original non-scaled mesh, use a MeshIdentifier to keep the scaled information in the name, but not to overwrite the original mesh. It's an optional standard, I could of called that mesh "Franky" as far as NxOgre cares, but if you use Franky you don't use mesh-scale in the Shape params, else it'll want an even larger Franky. Which is scary.

To save the scaled mesh to disk
NxOgre::ResourceManager::getSingleton()->saveConvexMesh("Franky", ResourceStreamPtr("file:franky.nxs"));


I'm still considering replacing "file:" and "ogre:" with "file://" and "ogre://" to make it more like a URI. At least then some genius can make an NxOgre plugin so this can be filled "http://". ;)

TriangleMeshes next!


* PrismShape which uses the convex system isn't working yet.

ebol

21-09-2007 12:08:08

Congrats on a good part of code written then :) Looks simple and powerful.

Caphalor

21-09-2007 16:13:08

Here is my Hardness Patch. :D
But I am confused a little. NxJointLimitDesc, Version 2.72:

/**
\brief [not yet implemented!] limit can be made softer by setting this to less than 1.

<b>Range:</b> [0,1]<br>
<b>Default:</b> 1.0
*/
NxReal hardness;

But the hardness parameter is used in some official PhysX examples.
I also changed some of your comments, I think you forgot to replace "Swing" with "Twist".

Edit: When I tried to implement control over the joint params in my editor I came to the conclusion that there are simply too much parameters to make it clear with CEGUI. I decided to use Ogre Cgf files to define "Joint Profiles" from which you can choose one in my Editor. If someone is interested, I could post the code for creating a JointParams Object from a Cfg file.

betajaen

21-09-2007 16:27:21

Thankyou for the patch, it's saved to the desktop and will be added later on today.

I'm a little confused with the hardness if it is used in the PhysX examples, why have a variable there in the first place if it isn't used?

Aiursrage2k

28-09-2007 00:42:22

There seems to be a problem when trying to create a trigger, it gives errors in the actordesc. I was unable to figure it out :oops:

betajaen

28-09-2007 09:38:33

There seems to be a problem when trying to create a trigger, it gives errors in the actordesc. I was unable to figure it out :oops:

What's the PhysX error? (It should be in the log), but usually triggers have to be kinematic or static.

luis

30-09-2007 10:46:23

I cant find the "upload a file" option in grouphub so i'll post the patch here.
It is far from beeing completed but fixes a memory leak in ActorGroup and in setcall back (using method pointers).

To be finished it should take care of multiple calls to setcallback....

here is the patch:
NxOgre09_rev38_2007093000_memoryLeakActorGroup.patch

Index: include/NxOgreGroup.h
===================================================================
--- include/NxOgreGroup.h (revision 38)
+++ include/NxOgreGroup.h (working copy)
@@ -92,15 +92,26 @@

//////////////////////////////////////////////////////////

- GroupCallback(InheritedCallback* cb) : mCallback(cb) {}
+ GroupCallback(InheritedCallback* cb) : mCallback(cb)
+ {
+ mCallbackOwned = false;
+ }

template <typename T> explicit
GroupCallback(T* v,
void (T::*Start)(Actor*, Actor*),
void (T::*End)(Actor*, Actor*),
void (T::*Touch)(Actor*, Actor*))
- : mCallback(new TriMethodCallback<T>(v, Start, End, Touch)) {}
+ {
+ mCallback = new TriMethodCallback<T>(v, Start, End, Touch);
+ mCallbackOwned = true;
+ }

+ ~GroupCallback()
+ {
+ if( mCallbackOwned )
+ delete mCallback;
+ }

//////////////////////////////////////////////////////////

@@ -119,6 +130,7 @@
//////////////////////////////////////////////////////////

ContactCallback* mCallback;
+ bool mCallbackOwned;

};

@@ -140,8 +152,9 @@

void setCallback(GroupCallback::InheritedCallback* cb) {
// std::cout << "Inherited Constructor (" << cb << ")" << std::endl;
+ delete mCallback;
mCallback = new GroupCallback(cb);
- mCallbackOwned = true;
+ //mCallbackOwned = true;
}

template <typename T>
@@ -152,6 +165,7 @@
void (T::*Touch)(Actor*, Actor*)
)
{
+ delete mCallback;
mCallback = new GroupCallback(v, Start, End, Touch);
}

@@ -167,7 +181,7 @@
NxActorGroup mGroupID;
Scene* mScene;
GroupCallback* mCallback;
- bool mCallbackOwned;
+ //bool mCallbackOwned;

static NxActorGroup mNextFreeID;
};
Index: source/NxOgreGroup.cpp
===================================================================
--- source/NxOgreGroup.cpp (revision 38)
+++ source/NxOgreGroup.cpp (working copy)
@@ -83,7 +83,7 @@
mScene->_unregisterActorGroup(mName);
mNextFreeID = mGroupID;

- if (mCallbackOwned)
+ //if (mCallbackOwned)
delete mCallback;
#ifdef NX_DEBUG
std::stringstream ss;

danharibo

08-10-2007 18:26:48

Betajean, do you intend to add support for the overhang tsm?
and is it possible to Rebuild the terrain collisions?

Aiursrage2k

11-10-2007 14:28:22

Some of the actors are not showing up in the debug renderer, a temporary work around
NxShape* const * shapeArray = actor->getNxActor()->getShapes();
shapeArray[0]->setFlag(NX_SF_VISUALIZATION,true);

betajaen

11-10-2007 17:03:39

Some of the actors are not showing up in the debug renderer, a temporary work around
NxShape* const * shapeArray = actor->getNxActor()->getShapes();
shapeArray[0]->setFlag(NX_SF_VISUALIZATION,true);

Fixed.

TMT

11-10-2007 20:11:29

betajaen,
suggest changing in NxOgreStable.h:
#include <ControllerManager.h>
to
#include <NxControllerManager.h>

I don't think you use the older deprecated ControllerManager. But I could be wrong.

betajaen

11-10-2007 20:56:02

I chose neither, and limited #include "NxControllerManager.h" to the files that actually need it.

Which I suppose is quite handy for those who don't want to use the character system at all, which is one less DLL for them. ;)

TMT

02-11-2007 21:04:48

What's the new target release date for the next revision?

betajaen

02-11-2007 22:18:59

Yesterday. :(

Once, I've ported triangleshapes, heightfields to the resource system it'll be out.

Chebastian

13-11-2007 11:08:22

sorry if its OT.
but im trying to create a characterController but i cant find the create method.

what i do is this:

NxOgre::CharacterController* mCControler;
//mCController = ???

the scene seems to only have a createCharacter method and no character controller. i'v probably overlooked something.

betajaen

13-11-2007 12:15:01

It's in Scene.

fzh

19-11-2007 11:07:56

hi, i have followed the instructions and got all the files, with proper links and environment entities. However I'm still getting these errors when compiling nxogre

1>NxOgreNxSerialiser.cpp
1>c:\nxogre\include\nxogreworldblueprint.h(58) : error C2039: 'cookerThreadMask' : is not a member of 'NxPhysicsSDKDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxphysicssdk.h(101) : see declaration of 'NxPhysicsSDKDesc'
1>NxOgreWorldBlueprint.cpp
1>c:\nxogre\include\nxogreworldblueprint.h(58) : error C2039: 'cookerThreadMask' : is not a member of 'NxPhysicsSDKDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxphysicssdk.h(101) : see declaration of 'NxPhysicsSDKDesc'
1>NxOgreEnumsBlueprint.cpp
1>c:\nxogre\source\nxogreenumsblueprint.cpp(1106) : error C2065: 'NX_TP_ABOVE_NORMAL' : undeclared identifier
1>c:\nxogre\source\nxogreenumsblueprint.cpp(1112) : error C2065: 'NX_TP_BELOW_NORMAL' : undeclared identifier
1>NxOgreForceField.cpp
1>c:\nxogre\source\nxogreforcefield.cpp(238) : error C2039: 'clothScale' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(241) : error C2039: 'falloffLinear' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(242) : error C2039: 'falloffQuadratic' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(243) : error C2039: 'flags' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(244) : error C2039: 'fluidScale' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(245) : error C2039: 'group' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(246) : error C2039: 'groupsMask' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(247) : error C2039: 'noise' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(250) : error C2039: 'positionTarget' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(250) : error C2039: 'positionTarget' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(251) : error C2039: 'rigidBodyScale' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(251) : error C2039: 'rigidBodyScale' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(252) : error C2039: 'softBodyScale' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(252) : error C2039: 'softBodyScale' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(255) : error C2039: 'velocityTarget' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(255) : error C2039: 'velocityTarget' : is not a member of 'NxForceFieldDesc'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxforcefielddesc.h(32) : see declaration of 'NxForceFieldDesc'
1>c:\nxogre\source\nxogreforcefield.cpp(257) : error C2039: 'createForceField' : is not a member of 'NxScene'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxscene.h(287) : see declaration of 'NxScene'
1>c:\nxogre\source\nxogreforcefield.cpp(264) : error C2039: 'releaseForceField' : is not a member of 'NxScene'
1> c:\ageia technologies\ageia physx sdk\v2.7.0\sdks\physics\include\nxscene.h(287) : see declaration of 'NxScene'
1>NxOgreDominanceGroup.cpp
1>c:\nxogre\source\nxogredominancegroup.cpp(101) : error C2059: syntax error : '}'
1>c:\nxogre\source\nxogredominancegroup.cpp(101) : error C2143: syntax error : missing ';' before '}'
1>c:\nxogre\source\nxogredominancegroup.cpp(101) : error C2059: syntax error : '}'
1>NxOgreScene.cpp
1>c:\nxogre\source\nxogrescene.cpp(426) : error C2065: 'mDominanceGroups' : undeclared identifier
1>c:\nxogre\source\nxogrescene.cpp(426) : error C2228: left of '.destroyAllOwned' must have class/struct/union
1> type is ''unknown-type''
1>c:\nxogre\source\nxogrescene.cpp(427) : error C2228: left of '.empty' must have class/struct/union
1> type is ''unknown-type''
1>c:\nxogre\source\nxogrescene.cpp(831) : error C2065: 'DominanceGroup' : undeclared identifier
1>c:\nxogre\source\nxogrescene.cpp(831) : error C2065: 'ddg' : undeclared identifier
1>c:\nxogre\source\nxogrescene.cpp(831) : error C2061: syntax error : identifier 'DominanceGroup'
1>c:\nxogre\source\nxogrescene.cpp(832) : error C2228: left of '.lock' must have class/struct/union
1> type is ''unknown-type''
1>c:\nxogre\source\nxogrescene.cpp(832) : error C2227: left of '->getName' must point to class/struct/union/generic type
1> type is ''unknown-type''
1>c:\nxogre\source\nxogrescene.cpp(833) : error C2065: 'mDominanceGroupsByIndex' : undeclared identifier
1>c:\nxogre\source\nxogrescene.cpp(833) : error C2228: left of '.lock' must have class/struct/union
1> type is ''unknown-type''
1>c:\nxogre\source\nxogrescene.cpp(833) : error C2227: left of '->getGroupID' must point to class/struct/union/generic type
1> type is ''unknown-type''

i'm using VS2005, ageia 2.7.2, latest version of ogre SDK, as well as latest version of NXogre downloaded from SVN, any idea what could be the problem? Thank you very much.

betajaen

19-11-2007 12:45:27

PHYSX_DIR environmental variable is pointing to an older version I'm guessing.

fzh

19-11-2007 13:19:39

i had 2.7.0 earlier but i had already uninstalled it, and I only have 2.7.2 version on my pc now. i'm quite sure the environmental variable is correct, otherwise it will return unable to open header errors. Is it possible that even the system software has to be reinstalled as well?

betajaen

19-11-2007 13:47:53

Nope. Nothing to do with the SystemSoftware, it's using the 2.7.0 headers. Which is why DominaceGroups are undeclared identifiers (they only came in after 2.7.2).

fzh

20-11-2007 04:37:20

alright, i found the answer, i guess even though i removed the older version SDK of ageia the compiler still retains the files used, I cleaned the solution then compiled again and it works perfectly. Well except for this error:

1>Copying DLL to CakeBox and Ogre Samples. Errors during copying process does not mean the library was built incorrectly.
1>The system cannot find the path specified.
1> 0 file(s) copied.
1>The system cannot find the path specified.
1> 0 file(s) copied.
1>Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

though the dll is already compiled so it's not much of a problem, and i guess i didn't put cakebox and samples in yet.

danharibo

28-12-2007 15:09:21

I'm getting about 385 Errors:
http://pastebin.ca/834868

Why does everything hate me :cry:

BonD

06-01-2008 11:55:32

fzh: This article is your friend: How to fix NxOgre's post-build errors

jchmack

11-02-2008 10:04:35

Um was 0.9-39 ever released? or did it just turn into what is now 1.0 bleeding? I wanna have the latest version but from what i hear bleeding isn't too stable yet.

betajaen

11-02-2008 10:38:06

I think it turned into Bleeding. Bleeding's pretty stable, it's just missing some core features at the moment; some shapes, cloth, fluids, characters, etc.

jchmack

11-02-2008 19:03:41

The main thing i need is characters. The reason i want to upgrade is because i am wondering if there is away to set the shapegroup of a character. But... seeing as 9-38 was the last release with characters i guess ill have to wait =).

betajaen

11-02-2008 19:07:52

You don't need an NxOgre wrapped function for that, just do it by hand. ;)

dekron

07-03-2008 16:16:40

hey everyone, i've got a little question about NxOgre's installation.

Is that mandatory to install first PhysX and TurtoiseSVN before NxOgre ?

spacegaier

07-03-2008 16:18:40

Should be done in this order. You will need PhysX to compile NxOgre.

When you install TortoiseSVN does not matter (has automatically to be done before installing NxOgre as you will get NxOgre via TortoiseSVN :wink: ).

dekron

07-03-2008 16:48:38

Do you mean than i can't download or use NxOgre without SVN ?

I don't have it, i know it is useful, but i'm not so familiar for the moment to tortoise, and i prefer using NxOgre without it in a first time, if possible

spacegaier

07-03-2008 17:24:45

As far as I know, NxOgre is only available via SVN. But using TortoiseSVN is really simüle (in fact I also used it for getting NxOge for the first time). Just download it install it and look at this: https://www.projects.dev2dev.bea.com/Su ... seSVN.html

For running or working with NxOgre you don't need it. You just need it to get it (better: to download the source code).

overburn

27-03-2008 20:22:56

well.. either i'm stupid.. or nxogre doesn't work with physx 2.8 for now.. right?

betajaen

27-03-2008 21:09:52

No, NxOgre 0.9 doesn't work with 2.8.0