1.0'22 - Unstable not even on the SVN release.TESTERS NEEDED
betajaen
03-09-2008 18:46:54
NxOgre 1.0'22
After 3-4 months wait, I'm publically releasing NxOgre 1.0'22.
However; not to confuse the newbies I won't be placing it on the SVN straight away, until I am satisfied that it actually works with the masses - due to the changes of the core parts.
If you have been using NxOgre for less than two weeks, and even attempt to download this file - I WILL LAUGH AT YOU.
Incomplete Release notes
1.0 '22
Changes
-------
+ New Betajaen container classes added and embedded.
+ Betajaen S11N classes added.
+ Betajaen S11N classes for PhysX added.
~ Rewrote the Raycaster class.
+ Added Prototype system
~ Changed Scene to use RenderableFactory
+ Added RenderableFactory class.
+ Rearranged the WheelSet, made ExtendedWheel a Wheel and allowed public access to the Wheels
shared list.
~ Resource System improvements
+ Body creation callback added
+ Moved some of the major containers to Mutable and ConstantMap.
+ Added support for Memory Macros changes in Ogre 1.6.0
+ Updated ActorParams to new Params style.
+ Moved to it's own header and source file.
~ Mass default is now 1.0f
+ BodyFlag struct to replace most of the BodyFlags (see FreezeFlag)
+ FreezeFlag struct to replace the NX_BF_FROZEN enum applied to the BodyFlags
~ When setting mass, the density is set to zero and vice versa.
Deprecation notice
------------------
ActorParams class in NxOgreActor.h/NxOgreActor.cpp
--------------------------------------------------
1. String parameters in ActorParams that are form of lineardamping, angulardamping, etc. are
now in the new form of linear-damping, angular-damping, etc.
2. Parameters that have two types of inputs; i.e. groups or materials now share the
same param name, and use a DualIdentifier<> class to represent them.
group: 1 (integer id)
group: red (string id)
------------------------------------------------------------------------------------------
To support your migration over to the new standards set. NxOgre will keep the old system
and the new system running until NxOgre 1.0'24. From that time onwards the new code will
exist and the old code will be removed.
It also has the fixes for interpolation and mesh loading.
Download
NxOgre-1.0-22.unstable.zip (423kb)
All problems, compile errors and thumbs up in this thread only.
If I see any posts outside this thread - I WILL DELETE THEM.
betajaen
03-09-2008 18:51:25
mcaden
03-09-2008 19:29:15
I plan on giving this a shot in the morning when I wake up.
almondega
03-09-2008 20:26:28
hi betajaen
i'm using ogre 1.6rc1 and the NxOgre '21, working perfect, i just commented out the header allocator problem
my game uses raycasting, and i see here that the code was rewrote
should i update to this or keep the working 21 ?
tks
Caphalor
03-09-2008 20:35:40
Compiling right now, the first thing I noticed is:
#if (NX_USE_OGRE == 1)
# include <OgreNoMemoryMacros.h> //Doesn't exist in Shoggoth anymore
#endif
But this is already known...
I'm compiling my game with the new NxOgre now.
betajaen
03-09-2008 20:53:54
@almondega
It's up to you really, obviously you can copy your project and try it out with '22, and see if it behaves the same as '21. But it is worth it alone for the new container system.
@Caphalor
Oops. Missed those.
#if NX_USE_OGRE
# if (OGRE_VERSION_MAJOR <=1 && OGRE_VERSION_MINOR <= 4)
# include <OgreNoMemoryMacros.h>
# endif
#endif
#if NX_USE_OGRE
# if (OGRE_VERSION_MAJOR <=1 && OGRE_VERSION_MINOR <= 4)
# include <OgreMemoryMacros.h>
# endif
#endif
reptor
03-09-2008 20:57:51
betajaen
03-09-2008 20:58:35
New Container system - example
Most people are probably unaware, that NxOgre is moving away from the STL container system. It's being replaced by my own system called "Betajaen's Container Classes or BetajaenCC".
In this example (taken from Cake), I am going to use a ConstActors and ConstActors::Iterators to move any actor below 0,0,0 and place it neatly above it. This is useful if you want to create a floor, and now have a sudden surge of actors coming out of the ground.
ConstActors actors = mScene->getActors();
ConstActors::Iterator iterator = actors.GetIterator();
for (Actor* actor = iterator.Begin(); !iterator.End(); actor = iterator.Next()) {
if (actor->isDynamic()) {
if (actor->getGlobalPositionAsNxVec3().y <= 0 ) {
NxVec3 globalPose = actor->getGlobalPositionAsNxVec3();
Shape* s = actor->getCollisionModel().Get(Actor::CollisionModel::First);
NxBounds3 bounds;
s->getNxShape()->getWorldBounds(bounds);
globalPose.y = 0.025f + ((bounds.max.y - bounds.min.y) * 0.5f);
actor->getNxActor()->setGlobalPosition(globalPose);
}
}
}
Simple!
betajaen
03-09-2008 21:06:28
Okay. I re-uploaded zip file with the fixes MemoryMacros thing; Nobody shouldn't have any problems with it now.
Caphalor
03-09-2008 21:14:25
I have problems with the new Raycaster class, because of its protected constructor and destructor (I can't create an object of this class
). Scene::getActorsFromRaycast seems to be unfinished...
betajaen
03-09-2008 21:22:23
It's now has factory methods in Scene.
mRay = mScene->createRaycaster();
mRay->origin(NxVec3(0,0,0));
mRay->normal(NxVec3(1,0,0));
mRay->distance(100);
mRay->type(Raycaster::RCT_Closest);
if (mRay->cast()) {
for (ActorRaycastHit* ar = ait.Begin(); ar = ait.Next();) {
std::cout << "'" << ar->mActor->getName() << "' @ " << ar->mDistance << "m" << std::endl;
}
}
mScene->destroyRaycaster(mRay);
Edit: I filled out that function for you.
Caphalor
03-09-2008 21:33:54
Now everything compiles fine, but NxOgre crashes while initialising.
I can't even give a detailed description of the error, I have to do some additional debugging.
betajaen
03-09-2008 21:39:32
Hmm. I was afraid that may happen, I think it may be due to the ActorParams class.
Caphalor
03-09-2008 21:50:38
The debugger says that it happens here:
SceneParams(const char* _params) {
setToDefault();
process(_params);//!!
}
I call it this way:
mScene = mNxWorld->createScene("MyScene", mSceneMgr, "renderer: ogre, controller: accumulator, gravity: yes");
Edit: I now use NxOgre::SceneParams directly and it works, but there is a similar problem with actor string params. Could you provide an example how to use the new system?
betajaen
03-09-2008 22:06:25
Yep. I thought it was that specific code, I was getting similar problems and came to the conclusion it was Cake.
I'll do some more investigation; but it may be BetajaenCC related.
[Edit]
Fixed the crashing, it was due a weird NxArray not being initialized - I changed it to a std::vector until I have time to implement it using BetajaenCC. Now getting some weird behavior of the strings not being parsed properly.
But until tomorrow, use the class version.
[Edit2]
The weird behavior (cubes falling through the floor) was me being stupid and forgetting that I didn't have a floor in the Scene. Still getting some minor issues, and I need to make double sure that the flag parsing code is working.
I'll post a fix tomorrow.
mcaden
04-09-2008 09:32:32
Alrighty, lets give this a shot...
using eihort - 1.4.9 + NxOgre 1.0'22 unstable...
downloading...done
renaming old NxOgre folder, extracting new NxOgre folder...done
open .sln and set the include directories and lib directories...done
build in debug...success
build in release...fail, can't open program database on 4 files...cancel build, try again...success
build my program...errors
Errors due to the changes in actorParams as expected...figuring out how to use freeze flag stuff, and also noticing the way to set actor groups has changed...done, rebuild...errors?!
Apparently Scene::CreateBody now returns an Actor* instead of a Body*? Okay, change datatype as, if I remember right, most of the functions were actually the same anyway...build...success!
Run...Fatal Exception as described above...I'm looking for it now.
mcaden
04-09-2008 09:42:17
nxArray.h
NX_INLINE void pushBack(const ElemType& x)
{
//insert(end(), x);
if (memEnd <= last)
{
reserve((1 + size()) * 2);
}
*last = x; // <<-- crashes here - bad ptr
last ++;
}
It looks to be during the World constructor. x in this case reads "use-log: yes".
betajaen
04-09-2008 09:50:42
I've solved that bit, and found a strange bug with the DualIdentifier which was causing every actor to have random groups, dominance groups and materials. Which was causing static actors to not be created.
I've applied a fix for that now, but I'm going to rewrite the DualIdentifier class again.
http://get.nxogre.org/releases/NxOgre-1 ... stable.zip
On that note; I'm going to have some Breakfast.
Caphalor
04-09-2008 11:18:28
Okay, this seems to work:
- Resource System
- Static Bodies
not working:
- dynamic bodies (they are always spawned at 0,0,0, I can't change their position, they don't fall down...)
betajaen
04-09-2008 11:23:59
Strange. You have a time-controller right?
mWorld = new World("time-controller: ogre");
mScene = mWorld->createScene("Eddie", "renderer: ogre, controller: accumulator, gravity: yes, floor: yes");
for (int i=0;i < 16;i++) {
Body* b = static_cast<Body*>(mScene->createBody("cube.1m.mesh", new Cube(1), Vector3(-5, i * 2.5f, 0), "mass: 100"));
b->setRenderMode(RenderableSource::RM_Interpolate);
}
Caphalor
04-09-2008 11:27:15
I call NxOgre::World::simulate manually.
betajaen
04-09-2008 11:34:23
You should call PhysXDriver simulate not World (it's better) and Are you calling render?
Caphalor
04-09-2008 11:43:57
Ok, the bodies are falling down right now and I can move them. (When I changed the scene params yesterday I simply forgot some -_-).
mcaden
04-09-2008 11:48:02
Latest build: compiles first time
good (could be caused either by new NxOgre, or the fact that I deleted a lot of unused shader programs): my FPS with vsync off skyrocketed by 100FPS
bad: jitter is worse
I'm going to dinner now, will do more testing later.
betajaen
04-09-2008 11:50:26
@Caphalor
Intresting. Did you try that code I posted?
@mcaden
I'll go with the new NxOgre that is causing the 100FPS increase
But how is the jitter worse? Your using the accumulator and body interpolation?
Caphalor
04-09-2008 11:52:59
Ok I think it's my mistake, I don't use NxOgre::ActorRaycastHitNodeIterator correctly.
EDIT: It works! Now finish the character system and I am really happy. XD
betajaen
04-09-2008 12:04:08
I'm glad to hear it (seriously).
Is your application faster now, or was it mcaden's shaders?
Caphalor
04-09-2008 12:13:50
I test everything within my Editor which has a fixed frame rate, so I can't answer... (I once built a simple fullscreen application which uses our Engine, but I never used it so I can't compare it with the new NxOgre). It is not slower.
reptor
04-09-2008 12:36:12
Easy fix to get rid of
"nxogre\source\nxogremesh.cpp(406) : warning C4018: '<' : signed/unsigned mismatch"
Replace
for (int i=0;i < coords->_size();i++) {
with
for (unsigned int i=0;i < coords->_size();i++) {
the coords->_size() returns an unsigned int and the other side of the comparison should be the same data type.
betajaen
04-09-2008 13:36:30
Thanks. I've been meaning to get rid of some of those warnings.
mcaden
04-09-2008 15:35:34
I'm convinced the problem I'm having lies in some trouble between my hardware and the time controller. If you think about it, my problems with jitter, animation, movement speed....all are related to time. It looks like my animation is skipping frames, the movement of the physics is dependent on my FPS, and the jitter is quite pronounced on this computer, but not on my other test machine.
Prophet
04-09-2008 15:46:41
Hm, I'm not sure if I'm supposed to post this here (or at all), but I thought you won't cut my head off if I do.
I read about
Inheriting Actor and especially the latest part about RenderableFactory. If I understand this correct (quite important for me at the time), from '22 and onwards we should create the "TestActor" (of course, our own replacement) and TestFactory (once again, our own) and then create bodies? That's what you recommend, right? Instead of synchronizing a Ogre::SceneManager with a NxOgre::Scene, or something other, equally foolish.
I got a bit confused with the Body-comment that says "...should not be used for anything serious".
betajaen
04-09-2008 16:17:55
"Body" is my TestActor implemented in NxOgre; just an example. It's become a generic term for anything that is an Actor but rendered. The NxOgre Body class itself it pretty dull, it assumes your using a single scenenode with one or meshes, doesn't take account for sound, events, AI and so on. Which is why it shouldn't be used for anything serious - it's dull and stupid.
When you create your own "Body" class and a Factory. You can go all out, add sound, events, AI, so forth. But the advantage is, NxOgre will treat it as it's own, and anything that requires a Body (i.e. mScene->createBody) - it will use YOUR class and not NxOgre's.
You should also take advantage of the RenderSystem in NxOgre to help you render your Actor, and not do it as you say "synchronizing a Ogre::SceneManager with a NxOgre::Scene, or something other, equally foolish".
@mcaden
Perhaps your application could take the accumulator approach like NxOgre has; smooth it out and keep a constant time-step.
mcaden
04-09-2008 16:23:18
Jitter problem: Barely noticeable at 60FPS on this computer...NOT noticeable on my wife's computer at all really. VERY pronounced at 200FPS, and even more so at 300FPS so it seems to get worse at faster speeds
Accumulator problem: Both my wife's computer, and my computer + all testers thus far report character movement dependent on FPS...at 300FPS he rockets all over the place, at 60 it's ideal, at 30 and below he walks and barely moves anywhere. (I have movement animations based on linear velocity...if linearVelocity.magnitue() > 10 - play running animation, otherwise play walking animation) the speed change is very noticeable.
Animation skipping: only happens on this computer
===========
so yeah, all seem related to time
I have made my basic level for testing available at
http://mcaden.katalyststudios.com/proje ... ha_0.1.zip
EDIT: this is not me hijacking Betajaen's nxogre '22 testing thread for testing my own game. This is showing the effect that building my game with '22 has, demonstrating the accumulator problem I'm seeing and the jitter bug evident when running the game at high FPS. I made it available for testing the NxOgre build. Feedback definitely welcome, but just making it clear that this is for NxOgre, not my fledgling game.
mcaden
04-09-2008 16:33:07
After upgrading to '22 my actorGroup collision callbacks don't seem to be working
EDIT:
void Player::onStartTouch(Actor* actorA, Actor* actorB, ContactStream* cStream) {
LogManager::getSingleton().logMessage( "StartTouch callback entered with actor from group: " + actorB->getGroup()->getName() );
String colGroupName = actorB->getGroup()->getName();
if( colGroupName == "terrain" )
mIsInAir = false;
else if( colGroupName == "enemy" )
{
//...
see that log entry?
After testing the game and colliding with things...there are no log entries.
EDIT2: Re: Jitter - Another tester reports it's not really noticeable at 60, but quite obvious when he turns Vsync off (~500 FPS for him), animation for him is smooth, and movement speed IS dependent on framerate...so the accumulator appears to not be working.
Prophet
04-09-2008 21:51:32
"Body" is my TestActor implemented in NxOgre; just an example.
Ah, so then you should use CreateBody, but with your own bodies. (Now that sounded strange)
Thanks, I was sure I chose the right physics and wrapper for Ogre, but you just continues to amaze me. If I had a life, I'd give it to you.
betajaen
04-09-2008 22:20:25
If I had a life, I'd give it to you.
Your a ROBOT!!?
@mcaden
I think my fix made groups of Actors use a weird group number or none at all. Any chance you can check to see if they are in the right group for me?
mcaden
05-09-2008 07:28:46
Sorry it took so long, I slept-in this morning.
This is my player code:
ActorParams ap;
ap.setToDefault();
ap.mMass = 15;
ap.mDensity = 0;
ap.mLinearDamping = 8;
ap.mAngularDamping = 10;
ap.mFreeze.mRotation.x = true;
ap.mFreeze.mRotation.z = true;
ap.mGroup = "player";
Ogre::AxisAlignedBox charBounds = mMainNode->getAttachedObject( mName )->getBoundingBox();
mBody = mScene->createBody(vp.mIdentifier, new Cube( charBounds.getSize() ), actorPose, vp,
ap);
LogManager::getSingleton().logMessage( "Player is in actor group: " + mBody->getGroup()->getName() );
Additionally I've added that logging statement to my terrain and enemy creation.
14:10:43: Found Terrain Object...
14:10:43: Setting Params...
14:10:43: Loading Terrain Object...room.mesh.nxs
14:10:43: Terrain is in actor group: Default
//...
14:10:43: Enemy is in actor group: Default
//...
14:10:45: Player is in actor group: Default
...hmm...I don't think you'd mess up THIS bad...lemme test some more...
mBody->setGroup( mScene->getActorGroup( "player" ) );
14:25:27: Player is in actor group: player
Heh, looks like I was setting the actor group wrong. Okay, apparently the way to set the actor group is NOT in the actor params. This includes string methods.
mScene->createBody(vp.mIdentifier, colMesh, actorPose, vp, "mass: 10, group: enemy");
Also ends up with the actor being in group Default.
betajaen
05-09-2008 07:44:17
No, it is the correct way. We are just having problems with the classes that replace the int/string combination for the groups and materials.
mcaden
05-09-2008 07:57:03
k, well they're in groups now supposedly, but still no collisions
EDIT: Oops! I had changed the function signature, that's why it wasn't being called...callbacks ARE working.
Aiursrage2k
05-09-2008 15:51:02
Finally its here, we should send betajean a case of beer.
Prophet
05-09-2008 16:11:17
Or two. (Who said I was a robot? I might be a bot...)
I guess you hate this question (sorry), but will there be any character implementation in the final release of '22?
betajaen
05-09-2008 17:02:53
@Airusrage2k
Unfortunately, I don't drink.
@Prophet
Nope. '22 will be as what we have here plus any fixes that may crop up in this thread.
mcaden
05-09-2008 18:09:50
"Body" is my TestActor implemented in NxOgre; just an example. It's become a generic term for anything that is an Actor but rendered. The NxOgre Body class itself it pretty dull, it assumes your using a single scenenode with one or meshes, doesn't take account for sound, events, AI and so on. Which is why it shouldn't be used for anything serious - it's dull and stupid.
When you create your own "Body" class and a Factory. You can go all out, add sound, events, AI, so forth. But the advantage is, NxOgre will treat it as it's own, and anything that requires a Body (i.e. mScene->createBody) - it will use YOUR class and not NxOgre's.
You should also take advantage of the RenderSystem in NxOgre to help you render your Actor, and not do it as you say "synchronizing a Ogre::SceneManager with a NxOgre::Scene, or something other, equally foolish".
@mcaden
Perhaps your application could take the accumulator approach like NxOgre has; smooth it out and keep a constant time-step.
1) So this is what
http://www.nxogre.org/Inheriting_Actor_ ... type_class is for. So if I attach a function to one of these that I've used inheritance with I can call that function from within a callback which takes an actor* like actorB->myCustomFunction?
2) Umm...I feel like an absolute moron...I was using addForce(...) for character movement...at 200+ FPS that adds up quite fast...using setLinearVelocity(...) my character is moving at the correct speed regardless of framerate. Accumulator is fine, I'm just calling the wrong function and feeling retarded.
3) I'm still having a bit of jitter, but I notice it's barely noticeable on my wife's computer. I seriously think there's something about my hardware that is aggravating it, I'm about ready to give up on both the jitter issue and the animation skipping as both being purely hardware related.
KevinMulder
07-09-2008 18:41:40
I did a short run on NxOgre:
Ogre: 1.6RC1
NxOgre: 1.0.22
Physx: 2.8.1 (software emulation)
OS: Win XP
IDE: VS2005 SP1
---- NXOGRE ----
NxOgre compilation: debug and release all fine. Testing will be done in the next day. I compile it with Qt accompanied and will test on both software emulated and 2x9800GT hardware physx supported box.
Results and stats will be posted here.
---- CAKE ----
Cake compilation: 101 errors, 1 warning ... maybe my fault
It does not find ClothVertex, RayCaster ( Physx include problem, I think)
Has ambigous Vector3 usage (OIS::Vector3 vs. Ogre::Vector3)
References NxOgre::Body->getEntity what is unavailable.
---- OTHER ----
Pls. do not cut my head
I use NxOgre since this friday. I switched from OgreNewt (since we should use tons of physics and would like to hardware accelerate that) I try to give reasonable feedback on NxOgre.
betajaen
07-09-2008 20:59:56
I did a short run on NxOgre:
Ogre: 1.6RC1
NxOgre: 1.0.22
Physx: 2.8.1 (software emulation)
OS: Win XP
IDE: VS2005 SP1
Cake is expected to fail, as I haven't released the latest version yet. But thanks for testing (it's glad to know that it works with Shoggoth, when I'm still using Eihort). Enjoy NxOgre.
@Everyone else
Which reminds me, how would people think of a function in flour to try to create a test scene, run a few tests and what not, then report what happened? It would seem a lot easier for me to know which is working and not if I have a single set of code to work from.
KevinMulder
07-09-2008 21:15:29
OFF
Oh
I sould thank you for the nxogre
ON
I am a bit stuck at the moment with 22. What I have is a box in the center of the scene. I have light, the camera is pointing to the box. But I cannot see the box nor the floor, only the NxOgre-debug wireframe of the box. It falls down the floor, so physics is okay, the rendering is screwed up somehow. I know I missed something, but I do not know what. Yet
So, I want to trade
I would like to ask You for a small but complete example (one box with one color is sufficient) I can compile on my host, so I can figure out what is wrong. In the return I give You feedback on it and write a step-by-step tutorial for the people switching to 22 in the future.
betajaen
07-09-2008 21:24:45
I'll write an example:
World* mWorld = new World("log:yes, time-controller: ogre");
Scene* mScene = mWorld->createScene("myScene", "renderer: ogre, controller: accumulator, gravity: yes, floor: yes");
for (int i=0;i < 10;i++)
mScene->createBody("cube.1m.mesh;Cube", new Cube(1.0f), Vector3(0, 2 + i), "mass: 10");
You can find cube.1m.mesh from the Cake media folder.
Prophet
07-09-2008 21:25:56
Tried with a code that you know worked with '21?
KevinMulder
07-09-2008 21:30:26
Silly me
Forgot to add "renderer: ogre" Now it is working nice.
(I still need some more experience before finishin up tutorial)
KevinMulder
09-09-2008 15:22:32
Step by step I progress. I had a cube on the floor, I had 5 cubes stacked, everything is working sound and stable. (Ogre 1.6RC1, NxOgre 1.0.22)
A problem arised though:
NxOgre::WheelParams wp("");
wp.setToDefault();
wp.mBrakeTorque = 0;
wp.mDensity = -1.0;
wp.mMass = 10.0;
wp.mMotorTorque = 50;
wp.mSteeringAngle = 0.0;
mScene->createBody("ca_wheel;car_wheel.mesh", new Wheel(1, wp), Ogre::Vector3(0,13,0), "mass: 10");
It falls through the floor and other objects. If I change it to new Cube(...), it stays nicely on the floor.
99% the solution is not defining WheelParams right.
1% something else.
Keep working on it, but if you see anything I screwed up, let me know.
Thanks
Prophet
09-09-2008 15:26:33
Hm, I just switched to '22 to test bodies fully, so this might be because of bodies.
So, I don't know how, why or when, but my program crashes when I'm using bodies and (I'm guessing), they're colliding. Not every time, just occasionally.it_foreach_backward(Actor* a, actors) { //<-!!!
if (NxStringStartsWith(a->getName(), identifier)) {
workingName = a->getName();
workingName = workingName.substr(identifier.length(), workingName.length() - identifier.length());
std::stringstream ss(workingName);
NxU32 current = 0;
ss >> current;
if (current > highest)
highest = current;
}
What I'm basically doing is creating a standard body usingmScene->createBody("Box01;Box01.mesh", new NxOgre::Cube(10.0f), Vector3(0, 100, 0), "mass: 10");
every time I press B. I also apply a force to the actor (the returned actor).
The Ogre-log says nothing (except unable to assign material) and the NxOgre-log says nothing. I ran in release, so I'll see if I can recreate the error in debug. I'll be back with more info.
Info: The debug-error says: Run-Time Check Failure #2 - Stack around the variable 'path' was corrupted. That's in betajaenaa.h though, line 436.
betajaen
09-09-2008 15:34:00
@Kevin
You need another shape with that Actor for that wheel to work; usually it's the car's chassis.
@Prophet
Intresting. I'm actually making a suite of test code right now in Flour; testing NxOgre. I'll try out your code in it, and see if I get any problems.
KevinMulder
09-09-2008 15:37:06
@Kevin
You need another shape with that Actor for that wheel to work; usually it's the car's chassis.
You mean like a box. And all Wheel shoud joined to it, right?
OFF
I owe you 2 big chocolates to You till this time
ON
Prophet
09-09-2008 15:45:07
I forgot to say; I'm using Eihort on this. I'll try upgrading to Shoggoth and see if there's a difference.
betajaen
09-09-2008 16:02:12
@Kevin
Yep.
You can either use a CompoundShape; Which creates all the wheels and chassis together, or create the Actor with the chassis first (usually a box or convex) then use actor->addShape for each of those wheels.
I like Chocolate.
@Prophet
I doubt it, so I wouldn't bother. I have found an issue with the params again. Creating the World twice with the second time as a string param causes a strange crash - but it's totally unrelated to your error. Once I've tracked that down, I'll work on replicating and coming up with a fix to your problem.
Prophet
09-09-2008 16:48:28
Neither do I, but sometime you "have" to migrate to Shoggoth, so I'll do it now anyway.
Right, apparently the uninstaller provided with Ogre removes the entire folder, so now I'll be spending the rest of the evening install everything again. Bug testing will have to wait.
Caphalor
10-09-2008 15:58:44
Is it possible that the _remove method in BetajenAA isn't finished (because of the #if 0 block)? That would explain why I have problems with deleting a body.
betajaen
10-09-2008 16:21:41
Yep.
Your right, I honestly thought I fixed that code.
Caphalor
10-09-2008 17:48:45
Will you provide a fixed version soon? Or is it enough to remove the #if 0 statement?
betajaen
10-09-2008 18:28:09
I'm working on it, but be warned. I haven't worked on that particular part of code in a few months.
betajaen
10-09-2008 19:06:55
Okay. I have a test application setup - with some newer code, it does execute _remove correctly now, but I want to make double sure it's working properly before I post a fix.
Luckly, I have a testing class in flour now.
Prophet
10-09-2008 19:49:43
When can we expect the new Flour to be release? As I've heard, it isn't far behind.
I guess the old Flour is still compatible with '22?
betajaen
10-09-2008 19:50:57
Flour has NxOgre in the executable, so in theory it doesn't matter what NxOgre you have - only if it can read NXS files.
But it should come out in a week or two, I really want to finish of this testing code first though.
Prophet
10-09-2008 21:41:49
I can now confirm, as expected, it makes no difference with Shoggoth or Eihort. I can also confirm, as expected, that converting takes alot of time for me.
betajaen
10-09-2008 22:09:27
I think it's related to the same error Caphalor found.
Prophet
10-09-2008 22:21:16
I did a bit of more testing, counting how many bodies I created.
1st time: 46.
2nd time: 46.
3rd time: 5442... Nah, 46.
This is global for
bodies not
actors. That is, I can create how many actors as I want, but only 46 bodies. So, perhaps it's my code, therefore it's available
here. It's crappy, but it's my experimental code so bare with it. The Body-creation is still the same.
I might add that I create the world "normally", but the scene is created in a frame-listener (as I said, it's experimental). I know I've had some issues with things created in the frame-listener.
Hope this might help!
betajaen
10-09-2008 22:25:32
No - your code seems fine.
I'm pretty sure it's to do with BetajaenAA, more specifically the tree code assigning NULL values to tree node's when it should be mTree->mNill. Causing the tree to go all weird once modified.
Prophet
10-09-2008 22:31:10
Hm, ok. I changed from string to the "standard" way (class? I never learn) and that didn't work either.
Well, once there's a fix, let me know!
spakowski
12-09-2008 10:20:29
Hi All,
Does 1.0'22 version of NxOgre supports Softbody Simulation if not which version of NxOgre should i use to get the complete cloth & Softbody support
betajaen
12-09-2008 10:37:32
No soft bodies have ever been done, but 0.9 has a working cloth system; which you can use to inflate a closed mesh which is quite similar to a soft body.
spakowski
13-09-2008 06:03:32
Hi All,
I read in one of the post about .Net wrapper for NxOgre that it will be ported for C++/CLI. Is this project continuing. Is there anyone working on this we are using MOGRE for our App/Game Developments in C# and we are stuck with Netwton Physics cause only MOGRENEWT is the available Physics Engine for Managed Ogre.
Will PhysX be ported for C++/CLI. We want to work on Cloth & Softbody simulation in the existing framework that we have developed using MOGRE for our applications.
Where can i find good tutorials or C++ to C++/CLI Conversion tools (if any available) for wrapping NxOgre to .Net
Betajaen Replied
"No soft bodies have ever been done, but 0.9 has a working cloth system; which you can use to inflate a closed mesh which is quite similar to a soft body."
When will NxOGRE Bleeding 1.0'22 stable version be available? When can we expect the cloth to be integrated with the this Version of NxOGRE?
Wea re almost planning to write our own custom NxOGRE .Net using the Physx-Sharp
http://imaginary-project.net/physx-sharp/ will this be a good option for now
Any suggestions or tips will be very useful for us.
Thank you
betajaen
13-09-2008 09:16:30
You can use NxOgre in C++/CLI applications; except the code would be "unmanaged". I've integrated NxOgre many times this way.
mcaden
17-09-2008 18:04:33
Another release soon?
I look forward to trying out that RenderableFactory system we've talked about in the other thread.
betajaen
17-09-2008 18:15:06
Still working on some bits on flour; I have a second project open with some prototype code for the RenderableFactory template code though.
mcaden
17-09-2008 18:21:13
ok
Not meaning to get impatient btw, just inquiring.
KevinMulder
17-09-2008 18:22:32
I am just testing 22 ... nothing to say about that. Everything works fine.
Caphalor
22-09-2008 21:33:53
Okay. I have a test application setup - with some newer code, it does execute _remove correctly now, but I want to make double sure it's working properly before I post a fix.
Your post is 12 days old - is the fix done? I can do some final testing if you want.
betajaen
22-09-2008 22:16:26
It didn't work. Neither did the rewrite (which took me two days).
I'm working from a different sort of Tree right now (It was Anderson but now it's a
Red-Black); so far my implementation of _insert and _clear seem to work; in a safe 5 line application. I need to finish it off first before I can put it into NxOgre, and see if it works properly.
I am getting quite annoyed about it though; I've spent on and off four months on the map code, if this doesn't work then I shall scream very loudly.
betajaen
22-09-2008 22:52:45
Oh Fudge.
betajaen
23-09-2008 10:25:47
Maybe not so much Fudge after all
It seems in tests with the Tree and Map classes using made up classes it works fine and sing the Tree and Map classes compiled into the NxOgre lib/dll also work fine.
But when using them with NxOgre classes it seems to go a little pair shaped; it might of been that the map/tree classes have always worked, but there is a bug somewhere in NxOgre that I must of missed.
More testing is required, but I would appreciate if anyone who has some spare time. Could they try testing the map/tree class in some sort sandbox application they have with the following code (and anything else they can think of) - Just to make sure.
#include "BetajaenMP.h"
#include <string>
#include <sstream>
class A
{
public:
A(int b) : a(b) {}
int a;
};
void test()
{
Betajaen::MutableMap<std::string, A*, Betajaen::_hasEach<std::string, A> > tree;
for (int j = 0;j < 100;j++)
{
for (int i=200;i > 0;i--)
{
std::stringstream ss;
ss << i;
tree.insert(ss.str(), new A(i));
}
for (int i=40;i < 200;i++)
{
std::stringstream ss;
ss << i;
tree.destroy(ss.str());
}
for (int i=200;i > 200;i--)
{
std::stringstream ss;
ss << i;
tree.destroy(ss.str());
}
tree.destroyAll();
tree.size();
}
tree.size();
}
void main()
{
test();
}
Map -> http://www.nxogre.org/screens/containers/BetajaenMP.h
Tree -> http://www.nxogre.org/screens/containers/BetajaenRB.h
[Edit]
I'm almost certain you can throw anything against that map now. It's only failing when it using pointers created within the NxOgre "dll memory space", I haven't tried anything with Ogre yet. However, I am going to try and see if the map iterators are causing any bother (swapping pointers around, messing around with the tree, etc.)
betajaen
23-09-2008 20:06:28
Okay, I'm going to abandon this release. I'm going to work from '21 (from the SVN again) and apply all the work and patches that have been applied in '22 except for the new container system.
I'm not giving on up that map system just yet - it will be in NxOgre. Just not this time.
mcaden
24-09-2008 05:41:44
will it have the CreateBody template?
betajaen
24-09-2008 10:09:16
I don't know yet. Most probably.
betajaen
24-09-2008 10:30:10
Actually, I was mulling it over in my head. And assuming the "map" part of the code works properly, I can replace much of the code with just standard STL either use it's tree, or just turn it into a light wrapper for it's map.
Either way, it would be a lot easier, and quicker to release.
Caphalor
24-09-2008 10:41:50
It sounds better than starting from 21' again.
betajaen
24-09-2008 11:42:04
Indeed.
However the mystery is; why does it work in NxOgre 1.1 codename "Bloody Mess" but not in Bleeding.
Prophet
24-09-2008 13:58:21
adc2008
28-09-2008 12:46:00
Hello betajaen ,
So, I used 0.4 when it was new, played with the demo's and went the way of ODE shortly after, I think it was because PhysX was questionably commercial and not as free as it is today.
Anyway, I must implement some advanced physics in my application, Cloth, Character and a kinematic like skeletal rig that matches a skeletal animation, enabling things like characters to kick coke cans, realistically walk though door curtains etc.. You get the idea.
So, I have learned from the forums cloth and character where implemented in 0.9, but are now broken/not implemented in 1.0, this seems like NxOgre is going backwards, losing features.
I figure there is a good reason for it, but I am a little confused about why you would release a newer version with less features, perhaps it is because of a full rewrite of those features.
Anyway, I played with 0.9, and I have played with cloth and character and some joined up kinematic actors rig in 0.9 & Ogre 1.6, I figured I would port cloth and Character class back into the latest version and release a patch for anyone who wants it if it wouldn't take to long, kind of on a tight schedule, but then I notice this in the 22 change log, and mentioned on the forums more than once.
1.0 '23
Aims
----
Character System
+ Port NxCharacter.dll over
+ KinematicCharacter Controller implemented
+ Character implemented
+ Performer implmented
+ CharacterModel implemented
+ MovementModel implemented
Cloth
+ Cloth class implemented
+ Cloth mesh implemented
+ Load cloth through resource system implemented
+ Rendering of cloth implemented (Sheet class)
+ Cloth raycasting implemented or amended to raycaster class.
ContactModifier (see NxUserContactModify)
+ Implement class
Implement into Scene
This is of course great news, because all of these features are cool.
Perhaps I could get a few things done if I find time to speed things along, but no need for me to do things that are already or partly done.
Anyway, I am just wondering where exactly you are betajaen, and if porting the cloth and Character across from 0.9 would be good or just silly, and when 23 may see the light of day, I'm guessing it's months away
betajaen
28-09-2008 13:06:13
Those are just "aims" of that release, but due to the problems posted in the last few pages. Sadly those features will be pushed back, to release '22/'23 in a realistic time-frame. Remember; It's only me who is working on this project in my spare time.
But your more than welcome to try and port the cloth/character code over.
adc2008
28-09-2008 13:11:55
Ok, I understand, I will have a go at porting the cloth & character over to the last SVN stable version since this 22 is unstable, perhaps I will have a go at getting it working in this release too, though it hopefully won't be a pain
betajaen
02-10-2008 13:10:34
Little update
Using the stl map was a failure, I've given up on that release and code now, and grabbed a fresh copy of 21 of the SVN.
I've put in destroyActors() which now makes flour 0.3 happy, and implemented the template body stuff which now just needs some testing.
mScene->createBody<MyBodyClass>(...);
After that applying the fixes for the resource system and then I'll copied some of my changes over.
betajaen
02-10-2008 20:34:44
Good news.
Cake and Flour works with NxOgre 1.0'22T2, I'm going to add the resource system fixes and post a copy tomorrow.