[Blog] Detritus/Traumatic - Character Controller implemented
betajaen
15-10-2009 16:07:42
NxOgre 1.6.0 "Detritus"
Although NxOgre 1.6.0, can be found in the "Detritus" branch at GitHub. It is recommended for all but seasoned NxOgre Users to use the existing "master" branch. A lot of things are being changed for the better and new features are being added, for that the interface will change, and existing things may break. If you HAVE to use Detitrus for some reason, keep any questions/problems in this thread only - until Detitrus has been declared stable.
This is the Blog post about Betajaen's efforts programming Detritus.
betajaen
15-10-2009 16:08:31
ptr_containers and Paths
One of the first acts of Detritus was to move away from the existing container system (although still retaining the fantastic Buffer class), and move over to the STL namespace. Initially, I started to use the Boost ptr_container classes, but found their use of references over pointers annoying.
Eventually, I wrote my own ptr_container classes; These are ptr_vector, ptr_map, ptr_multimap. BloodyMess does not have a map container, so to make use of the existing naming system, I decided to make all major classes be stored in a multimap container rather than the defunct Array class. To help with speed and iteration, Detritus stores a Hash of the name of the class along with the name. If you peek at the source of Scene, Actor, SceneGeometry and so on you’ll see new getNameHash functions.
All map and multimap containers don’t use std::strings as keys, the use the hashes -- much faster than strings, and easy to know by simply looking at the value of key, if it’s a non-named or named class.
The second big change of Detritus was re-doing the ResourceSystem, although hesitant at first. I was finally forced to admit that the ARI and URI classes were terrible and I needed a better solution. Using Boost as inspiration again, I fell in love with Boost.Path. Although forcing users to download a massive library such as boost, and incorporate into their application wasn’t acceptable. So I wrote my own.
Mesh* mesh = NxOgre::MeshManager::getSingleton()->load("file://C:/Program Files/myGame/media/goldfish.nxs");
The second big thing is, you don't need to use Archives anymore. Although Archives are still in there internally, and technically you can use them. You don't need as they are created automatically for you when dealing with paths. If your application is small, you may never see an Archive pointer!
For those who do need them, there are plenty of fast functions involving String Hashes and relative paths in Archives to keep you busy.
betajaen
15-10-2009 16:09:44
Fluids
Fluids is one of the big things I want for Release Day. It’s partly implemented in Git, although it does nothing. The constructor is basically empty and the functions are just wrapping code.
In Detritus -- Fluids actually work;
http://www.youtube.com/watch?v=5BuIw0D92KI
So far, I’ve only two methods of rendering; point based and velocity based (as in the video). I’d like a third using the Ogre Particle system to allow rendering of simple gases. But the API is open enough for someone to write a marching-cubes version for me.
As with all NxOgre code, Fluids are dead easy to create:
NxOgre::FluidDescription desc;
desc.mMaxParticles = 10000;
desc.mKernelRadiusMultiplier = 2.0f;
desc.mRestParticlesPerMetre = 7.0f;
desc.mMotionLimitMultiplier = 3.0f;
desc.mPacketSizeMultiplier = 8;
desc.mCollisionDistanceMultiplier = 0.1f;
desc.mStiffness = 50.0f;
desc.mViscosity = 40.0f;
desc.mRestDensity = 1000.0f;
desc.mSimulationMethod = Enums::FluidSimulationMethod_SPH;
desc.mFlags |= Enums::FluidFlags_Hardware;
fluid = mRenderSystem->createFluid(desc, "BaseWhiteNoLighting", OGRE3DFluidType_Velocity);
FluidEmitterDescription edesc;
edesc.mPose.set(0, 5, 0);
edesc.mParticleLifetime = 4.5;
edesc.mRate = 250;
edesc.mType = Enums::FluidEmitterType_Pressure;
edesc.mRandomAngle = 0.25f;
edesc.mRandomPosition.set(0.25f, 0.25f, 0.25f);
edesc.mReplusionCoefficient = 0.02f;
emitter = fluid->createEmitter(edesc);
I’ll keep you posted.
betajaen
15-10-2009 23:43:15
OGRE3DParticleRenderable
I've added the really simple binding, to render fluid particles into the Ogre Particle System. To celeberate this, I played around in Cake and a made a really slow moving, low density gas*.
* Okay, Technically it's a fluid in zero-gravity, but what you going to do?
waffleShirt
16-10-2009 04:30:24
Wow looks amazing, cant wait to get my hands on 1.6.0. Any time frame on a release?
spacegaier
16-10-2009 07:53:00
Well, all the code is on github. Just select the "Detritus" branch instead of the normal one and grab it
. But be aware that it is not declared as stable yet.
danoli3
16-10-2009 14:18:30
Nice work betajaen! Really awesome!
KyleKatarn
17-10-2009 16:03:13
Thats awesome man. I've noticed that the box stack seem to tumble over as soon as its spawned, is it meant to do that? Or is it being caused by the gases? If so, I think I've found a bug. =P
Keep it up =]
betajaen
17-10-2009 16:24:15
No, not a bug.
The boxes being teleported instead of being spawned, except they still have momentum from the previous frame so the stack quickly fall apart.
betajaen
17-10-2009 16:43:09
Eye Candy
I surrounded the emitter with Actors with cubes; acting as a hollow invisible box. Then I turned up the emission rate and maximum amount of particles
It takes the shape of the box!
betajaen
17-10-2009 19:54:14
Exceptions
Like Ogre, Detritus now throws Exceptions when dealing with critical errors. In Bloody Mess the standard behaviour was to return null and let the application crash.
With the new Exceptions, I can still make the application crash, but Visual Studio has a better chance finding the problem for the user, with the existing "Reason" system that analysis why the error occured in the first place, the user can have a pretty good idea what went wrong.
For example; In the following screen shot, an exception has occurred when running Cake, and Visual Studio has traced the problem to the following line in the left hand pane; the Actor wasn't created - which caused the exception. But why wasn't the Actor created? Well in the Dos Box (and in the log file) - NxOgre has discovered the reason why PhysX didn't create the error; The mass and density in the RigidBodyDescription are both zero in value. This is shown to be correct, by looking at the source of the problem highlighted in right hand pane.
Simple and neat, and supported already by most classes:
waffleShirt
19-10-2009 12:21:13
I feel kind of dumb for asking this, but after trawling through the Cake source code for a while I am still confused.
How has resource loading changed in NxOgre 1.6.0? I know that 1.6.0 has a lot of interface changes and hence does not work with the code that I wrote to work with 1.5.5. Im trying to upgrade an application to work with 1.6.0 but I do not understand how archives are opened and resources are loaded now. A small explanation or example code would be much appreciated.
Thanks
betajaen
19-10-2009 13:21:27
I merged your topic into this one.
Yes, it has changed, simply put archives are a less of an issue and can be completely ignored if you wish.
Say you have your "nxs" files in a folder called "media" in your executable folder. You access it via the "path" class, which is a merging of the old ARI and URI classes, into something more understandable:
NxOgre::MeshManager::getSingleton()->open("file://media/frog.nxs");
Using the file protocol, open the directory "media" in the current working folder, and access the file named "frog.nxs". Using that Resource load it as a mesh, and name it frog.
If this is the first time you've accessed the media folder then the archive "media" will created named "media" - if it's not, then it's fetched and used. You can pre-create archives if you so wish, but generally I recommend just doing it the new way.
waffleShirt
19-10-2009 13:30:42
Thanks heaps, ill try it out first thing tomorrow. Thats definitely a lot easier than the pre 1.6.0 way of doing it.
Will the visual debugger be restored to the way it was in NxOgre 1.5.4 in 1.6.0? Or is that something that will be left in the half finished state that it was in 1.5.5? Its not a major thing but I do like to have as much visual debug info as possible
Thanks for the quick reply, the community support behind NxOgre has made it accessible even to a newbie like myself.
betajaen
19-10-2009 13:50:30
The VisualDebugger is working, even better than 1.5.5.
waffleShirt
20-10-2009 00:06:36
I tried loading a mesh today using:
NxOgre::Mesh* mesh = NxOgre::MeshManager::getSingleton()->load("file:E:/Project/Build/data/models/cubePhys.nxs");
However I get an assert error saying that a list iterator is not dereferencable, this happens if I use the full path to the file as well. The error seems to be coming from line 244 of NxOgrePath.cpp. Not sure if this is a bug, but the code in NxOgrePath.cpp is:
if (parent_level == 0)
return (*mDirectories.end());
Wont that be a problem because it is returning one past the end of the list, which is undefined data?
I modified the code to return the last element in the list which helped me get a little further, but then when NxOgre tries to open my resource it throws a PathInvalidException. I cant figure out why this is happening, but when the code reaches line 85 of NxOgreFileResource.cpp no path is set for the file to be opened. I also tried loading a file with a relative path (
file://../data/models/cubePhys.nxs) but when NxOgre tried to load the file it once again throws the exception, this time thinking that the path to my file is "../data/data/models/cubePhys.nxs"
Any help would be much appreciated.
betajaen
20-10-2009 10:55:06
It's:
file://E:/Project/Build/data/models/cubePhys.nxs
Note the "//" after the first ":" If not, it thinks the entire string is the resource protocol.
But your right about the .end() part, also try the relative path as
file://./../data/models/cubePhys.nxs
waffleShirt
20-10-2009 23:10:49
Whoops, my bad on that one. I had the file:// bit in my project but typed it out wrong here.
I tried using the code you suggested for relative paths but im still having problems. In NxOgrePath.cpp there is a for loop from line 141 to 150 that modifies the list of directories in the path to the file to be loaded. Before the loop starts the directory listing is:
.
..
data
models
After the loop runs the list is
.
..
data
models
data
models
So NxOgre thinks I am loading a file from ./../data/models/data/models/cubePhys.nxs
Is there a logic error in that loop somewhere? I have commented out the loop and rebuilt NxOgre and I have no problems loading files after that.
betajaen
20-10-2009 23:17:30
There must be. When writing the path code, I did try an extensive test for paths, and I'm nearly positive that I tried one out for "../test1/test2".
I've just installed Windows 7, so everything needs reinstalling and compiling again. So I'm going to be a few days before everything is back as it was. One thing I could suggest, if you could try and fix it for me. I think I know what is your problem is. So roughly, at line 497. Have the following
if (path[pos] == PathHelper::parent_marker() && path[pos + 1] == PathHelper::parent_marker())
mAbsolute = false;
Then try this as your path:
file://../data/models/cubePhys.nxs
waffleShirt
21-10-2009 00:10:01
Im trying to fix it now but I dont quite understand what it is that needs to be done. Starting from line 496 im doing the following to check for a parent marker
t = path.substr(pos, 2);
if (t == PathHelper::parent_marker())
mAbsolute = false;
I ran the code and when I reached that code mAbsolute was already set to false, and then when I went to my next breakpoint after that for() loop I mentioned earlier my file path still comes up wrong.
betajaen
21-10-2009 00:13:06
Urgh...I'll try and have a look tomorrow for you. If the path is not absolute in that loop, then the ".." behaviour shouldn't be happening. Your saying it isn't absolute when it encounters that loop, which puzzles me.
waffleShirt
21-10-2009 00:36:57
Thats cool, Ill stick with my workaround of commenting out that loop for now.
Id try and explain what I think that for loop is doing wrong in NxOgre::Path::operator/ but after looking at it for a while Im more confused than ever. Thanks for all the help so far.
carlosmorcerf
22-10-2009 17:16:07
fantastic job!
betajaen
22-10-2009 19:31:43
I tried using the code you suggested for relative paths but im still having problems. In NxOgrePath.cpp there is a for loop from line 141 to 150 that modifies the list of directories in the path to the file to be loaded. Before the loop starts the directory listing is:
Okay. I've made a unit testing app called Soy. It only
tests the Path class at the moment, but with some modifications to the Path code. It now passes all of the situations I can think of and yours above.
So you may want to fetch the latest Detritus and try it out.
waffleShirt
23-10-2009 13:49:58
Awesome, ill update my code as soon as I can to go along with the changes and post my results.
Is the process for loading models the same as the last version of Detritus? Or is it back to the way things were done in 1.5.5? I just did a quick build of my code and it looks like the old ARI/URI system is back but its late and I might be imagining things.
betajaen
23-10-2009 14:10:38
It shouldn't be the ARI and URI classes have been removed, and the MeshManager uses the Path system now anyway.
So it goes:
NxOgre::MeshManager::getSingleton()->open("file://../data/models/cubePhys.nxs");
(Archive will be named models, and Mesh name will be cubePhys)
waffleShirt
23-10-2009 14:24:42
I tried the line you posted which had a compile error (open is not a member function, had to change it to load).
So now I have:
NxOgre::Mesh* mesh = NxOgre::MeshManager::getSingleton()->load("file://../data/models/cubePhys.nxs");
After stepping through the code no model is loaded. In ResourceSystem::open no archive is found in mArchives[] that matches the hash of the ARI for the resource to be loaded and NxOgre throws an error. Im not sure if I have missed anything but ill go over my code again properly tomorrow.
betajaen
23-10-2009 14:30:23
If there is a reference of "ARI" or "URI" as a class anywhere in the NxOgre you downloaded - then it's not detritus.
waffleShirt
23-10-2009 14:40:58
I grabbed the latest version from GitHub and it's not Detritus. I browsed the GitHib repo and what I am downloading is not what GitHub is listing. How can that be?
betajaen
23-10-2009 16:04:37
waffleShirt
24-10-2009 00:15:09
I was definitely downloading from the detritus branch last night, and I followed your direct link this morning and I am still getting the wrong version. I even cloned the repo using sysGIT and still get the old version.
Can anyone confirm they are getting the correct version of NxOgre from the link betajaen posted? If you have the correct version inside the archive downloaded under build\msvc you will have a file called NxOgre.Detritus.VC9.sln, if not it will simply be NxOgre.VC9.sln
betajaen
24-10-2009 01:25:47
URGH!!!!!!! Yep. Your right.
X:\downloads\betajaen-nxogre-ae8013b.zip\betajaen-nxogre-ae8013b\build\source\NxOgreStable.h
#define NxOgreVersionMajor 1
#define NxOgreVersionMinor 5
#define NxOgreVersionRelease 6
#define NxOgreCodeName "Git"
N:\projects\nxogre.org\NxOgre\build\source\NxOgreStable.h
#define NxOgreVersionMajor 1
#define NxOgreVersionMinor 6
#define NxOgreVersionRelease 0
#define NxOgreCodeName "Detritus"
#define NxOgreBranch "detritus"
I'll try another Git commit for you tomorrow. Git GUI is insisting in committing every file again, it may be related to me installing my OS again. I'll see if that works, and post my efforts here.
Thanks for bring this up, and apologies for not believing you the first time.
lombera14
24-10-2009 16:05:19
Hi Betajaen!!
It's nice to hear about "Detritus" and all its awesome features. It's also really good Visual Debugger is already restored in this version
By the way, is the KinematicController ready in Detritus???.
or at least have you found the way of colliding with static scene geometries???
My team and me are very happy with the work you are doing(really useful for us), and also
expecting for this issue gets solve. I'm sure there are a lot of people expecting for this as well.
Thanks anyway for all you are doing
Best Regards
Lombera
betajaen
24-10-2009 16:53:50
I may (stress may) found the reason why the KinematicController didn't work. I fixed the problem, but now I can't remember what the problem was. I haven't tested it though. But it was clearly evident from the code why it didn't work. I wish I remember what the problem was though.
Anyway, still working the next git commit. I've removed the PointerClass and replaced with something a bit better and modelled off the Ogre memory allocator system, meanwhile I'm dropping the blueprint classes in favour of descriptions now. So I need to finish up materials before I can commit again.
betajaen
25-10-2009 11:17:32
Okay the Git Commit is up with the new Allocation code and some cleanup of the files.
I think there is a bug with GitHub as it's confusing the download link between detritus and the master branch, however:
http://github.com/betajaen/nxogre/archives/detritus
Works.
waffleShirt
25-10-2009 12:38:44
Yay working GitHub commits again!
And as always the bearer of bad news:
error C2662: 'NxOgre::BoundsT<VecType>::isEmpty' : cannot convert 'this' pointer from 'const NxOgre::Bounds3' to 'NxOgre::BoundsT<VecType> &'
Thats line 120 of ogre3dparticlerenderable.cpp
betajaen
25-10-2009 12:49:35
I thought I fixed that!
betajaen
25-10-2009 12:54:29
Alright try it now.
waffleShirt
25-10-2009 13:12:59
Compile: Success
Run: Fail
Still getting the problem of the path to the file getting messed up with duplicate folder names:
NxOgre::Mesh* mesh = NxOgre::MeshManager::getSingleton()->load("file://./../data/models/cubePhys.nxs");
Results in NxOgre trying to load the file from
../data/models/data/models/cubePhys.nxs
NxOgre::Mesh* mesh = NxOgre::MeshManager::getSingleton()->load("file://../data/models/cubePhys.nxs");
Results in NxOgre trying to load the file from
../data/data/models/cubePhys.nxs
And it looks like its happening because of that for loop I was mentioning many posts ago. So right now you are probably wanting to kill me. Its late here and as usual I will double check all this in the morning.
Is there something I can do in Soy to test paths on my own system?
betajaen
25-10-2009 13:23:42
But I don't understand, your path in Soy parses fine.
NxOgre::Path path("file://../data/models/cubePhys.nxs");
The "dump" function in debug shows this;
Path
----
Full: file://../data/models/cubePhys.nxs
Is Relative: Yes
Protocol: file
Directories2:
2 : models
1 : data
0 : ..
File: cubePhys
Extension: nxs
And the OS String (which FileResource uses) is:
../data/models/cubePhys.nxs
I would double check, because I'm positive I fixed that loop problem.
waffleShirt
25-10-2009 13:42:07
Ill go over it carefully in the morning. I also tried with an absolute path and that failed even harder with the OS string being completely blank.
Ill try and give you as much information as I can. Hell if you really want to make things painful I can give you to access to my SVN repo and you can step through it line by line.
Sorry to be such a pain in the butt, I really appreciate all you've done to help me with this.
betajaen
25-10-2009 14:01:02
It sounds like your using old code.
For the sake of elimiating GitHub, download and install over the existing NxOgre you have with the attached file. Making sure to recompile everything.
I'll remove the file once you've downloaded it.
waffleShirt
25-10-2009 14:11:50
No difference...
It all falls apart when this line is called in NxOgreFileResource.cpp
mFilePath = mArchive->getPath() / mPath;
Inside that operator/ something strange happens and mFilePath ends up being an invalid file path.
betajaen
25-10-2009 14:18:09
Okay. I'll try a real world code in Cake and see if I can make it crash.
waffleShirt
25-10-2009 14:58:58
Ok then, I look forward to seeing how it goes.
Ill look over all my code again in the morning, debugging at 2am is not helping.
lombera14
26-10-2009 23:25:09
Hi Betajaen,
I'm sorry about the delay in responding, but actually I was involved in many other stuffs. Now I'm back.
Wow!!! It's really awesome you have found what the KinematicController problem was. It's pretty obvious you don't remember the reason for which it didn't work, but, could you at least tell me any hint to find the bug, in order I could make it works in my source????
Thanks in advance
Lombera
betajaen
26-10-2009 23:43:06
Wow!!! It's really awesome you have found what the KinematicController problem was. It's pretty obvious you don't remember the reason for which it didn't work, but, could you at least tell me any hint to find the bug, in order I could make it works in my source????
I really cannot remember why. I think it has to do with sweeping, and to be honest I haven't tried out the KinematicController since. You can always try Detritus with your existing App and see how it works.
waffleShirt
28-10-2009 06:32:38
I have put together a demo app that shows the path problems I have had with NxOgre recently. This is a completely seperate application from the one I was originally having problems in and the same problems persist.
Starting from line 107 of the NxOgrePathTest.cpp file you will see the test cases and a line stating if they pass or fail. I also set a breakpoint on line 89 of NxOgreFileResource.cpp to check the os_path string. As I stated previously it looks like the path gets corrupted on line 85 of the same file after the operator/ completes.
Included in the zip file is the version of NxOgre I built against and the actual project used for testing. These simply need to be built in the order of NxOgre and then NxOgreTestPath. No dll files need to be copied to the working directory, all dll's are included or copied in at link time.
Hopefully from this you will see the problem I am having, or you will see what I have done wrong and see how dumb I am.
The archive is too big for the NxOgre forums so I have uploaded the archive to rapidshare. Its only about 3.80mb
http://rapidshare.com/files/298944333/NxOgre_Path_Test.rar.html
betajaen
28-10-2009 09:53:41
Thanks for the sample application. I wish more people would go to the trouble of that for me.
I get the error too, I have a few ideas why. But I'll keep at it.
waffleShirt
28-10-2009 11:16:07
No problems, I know how much easier it is to fix something when you have code that you can actually execute and step through.
betajaen
29-10-2009 12:51:15
Okay, I *think* I got it. There was two reasons why it didn't work.
1. I forgot to get rid of the directories in the path when passing it onto a resource; which was the reason why you had doubled directories. That was an easy fix with the new "getRelative" function (just copy over everything to a new path, except the drives and directories).
2. The FileResource protocol was reporting wrong archive name, so an existing archive was being used rather than creating one. I must of been half-asleep when I wrote that function!
Simply put, in the old code all of these paths, were given the name only as "models" to it.
file://data/models/
file://../data/models/
file://./../data/models/
file://../../../data/models/
file://./../../../data/models/
file://../../../../data/models/
file://./../../../../data/models/
Now, they are named properly, taking in the ".." into account with.
models#data
models#data#.1
models#data#.1
models#data#.3
models#data#.3
models#data#.4
models#data#.4
Note, the "." marker is being removed as well now. It used to be treated as a directory name but now it's ignored and the path is set as relative - which is the correct behaviour.
This is the full std::cout dump of what the paths are doing, so you can have a look at and see if it looks right to you as it does to me, I'll put up the commit.
=======================================
file://cubePhys.nxs
=======================================
file://cubePhys.nxs
Combining:
+ file://(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://cubePhys.nxs as read from working_directory
[-] Closing File Resource -> file://cubePhys.nxs did R: 96 W: 0
=======================================
=======================================
file://../data/models/cubePhys.nxs
=======================================
+ Pushing => '..'
+ Pushing => 'data'
+ Pushing => 'models'
file://../data/models/cubePhys.nxs
+ Calculating archive name from file://../data/models/cubePhys.nxs
Opening Archive with path: file://../data/models/
+ Calculating archive name from file://../data/models/
Opening file archive as 'models#data#.1' from 'file://../data/models/
[+] Opening File Archive 'models#data#.1' from file://../data/models/
Combining:
+ file://../data/models/(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://../data/models/cubePhys.nxs as read from models#data#.1
[-] Closing File Resource -> file://../data/models/cubePhys.nxs did R: 96 W: 0
=======================================
=======================================
file://./../data/models/cubePhys.nxs
=======================================
+ Working Directory marker
+ Pushing => '..'
+ Pushing => 'data'
+ Pushing => 'models'
file://../data/models/cubePhys.nxs
+ Calculating archive name from file://../data/models/cubePhys.nxs
Combining:
+ file://../data/models/(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://../data/models/cubePhys.nxs as read from models#data#.1
[-] Closing File Resource -> file://../data/models/cubePhys.nxs did R: 96 W: 0
=======================================
=======================================
file://../../../data/models/cubePhys.nxs
=======================================
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => 'data'
+ Pushing => 'models'
file://../../../data/models/cubePhys.nxs
+ Calculating archive name from file://../../../data/models/cubePhys.nxs
Opening Archive with path: file://../../../data/models/
+ Calculating archive name from file://../../../data/models/
Opening file archive as 'models#data#.3' from 'file://../../../data/models/
[+] Opening File Archive 'models#data#.3' from file://../../../data/models/
Combining:
+ file://../../../data/models/(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://../../../data/models/cubePhys.nxs as read from models#data#.3
[-] Closing File Resource -> file://../../../data/models/cubePhys.nxs did R: 96 W: 0
=======================================
=======================================
file://./../../../data/models/cubePhys.nxs
=======================================
+ Working Directory marker
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => 'data'
+ Pushing => 'models'
file://../../../data/models/cubePhys.nxs
+ Calculating archive name from file://../../../data/models/cubePhys.nxs
Combining:
+ file://../../../data/models/(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://../../../data/models/cubePhys.nxs as read from models#data#.3
[-] Closing File Resource -> file://../../../data/models/cubePhys.nxs did R: 96 W: 0
=======================================
=======================================
file://../../../../data/models/cubePhys.nxs
=======================================
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => 'data'
+ Pushing => 'models'
file://../../../../data/models/cubePhys.nxs
+ Calculating archive name from file://../../../../data/models/cubePhys.nxs
Opening Archive with path: file://../../../../data/models/
+ Calculating archive name from file://../../../../data/models/
Opening file archive as 'models#data#.4' from 'file://../../../../data/models/
[+] Opening File Archive 'models#data#.4' from file://../../../../data/models/
Combining:
+ file://../../../../data/models/(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://../../../../data/models/cubePhys.nxs as read from models#data#.4
[-] Closing File Resource -> file://../../../../data/models/cubePhys.nxs did R:96 W: 0
=======================================
=======================================
file://./../../../../data/models/cubePhys.nxs
=======================================
+ Working Directory marker
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => '..'
+ Pushing => 'data'
+ Pushing => 'models'
file://../../../../data/models/cubePhys.nxs
+ Calculating archive name from file://../../../../data/models/cubePhys.nxs
Combining:
+ file://../../../../data/models/(R)
+ file://cubePhys.nxs(R)
[+] Opening File Resource -> file://../../../../data/models/cubePhys.nxs as read from models#data#.4
[-] Closing File Resource -> file://../../../../data/models/cubePhys.nxs did R:96 W: 0
waffleShirt
30-10-2009 05:13:53
Looks good to me. Ill rebuild the sample application I wrote with the new code when its posted on GitHub.
betajaen
30-10-2009 11:58:34
There you go:
http://github.com/betajaen/nxogre/commi ... a8d628558f
I've left some of the debugging code in, so you may see some extra messages printed to the console. Once your application works, I'll remove them in the next commit.
waffleShirt
30-10-2009 13:10:48
All signs point to WINNER!
Test app runs, there are no crashes and all meshes are initialised properly.
Hopefully now I wont find any more big errors for you any time soon.
betajaen
30-10-2009 21:33:34
Great news!
I've removed the Path debug information now, so you can upgrade to the next commit if you like.
betajaen
30-10-2009 22:26:35
New Description proposal
In the next commit, I want to address the issue of "Blueprints" and "Description". For the sake of consistency I will be removing all Blueprints, and replacing them with Descriptions. Blueprints were an idea when I first wrote BloodyMess to help with serialisation, there are better ways of doing it, instead we have this horrible middle man class that is a waste of space and memory.
I've already done some of this with the WorldDescription and SceneDescription classes. Now with Shapes.
Current each shape constructor looks like this;
Box(const Vec3& dimensions, ShapeBlueprint* blueprint = new ShapeBlueprint());
It's freaking horrible, there's a new in there. Two reasons why this is bad.
1. Every new shape is allocating a piece of memory. Blueprints aren't always used, so a class is repeatedly created and destroyed with default information.
2. Some people don't like to see a pointer being created like that, they may not trust the Shape class to delete it correctly, although it will. But the user may not know that. In worse cases the blueprint pointer will be deleted twice. Which is bad.
This is my proposal:
Box(const Vec3& dimensions, const ShapeDescription& description = Shape::DEFAULT_DESCRIPTION);
1. DEFAULT_DESCRIPTION is a instance created once and destroyed at the end of the application, it's also "const" because it's shared. Shared opens the possiblitiy of one class affecting another, or the user unknowingly altering the Description - which will cause all future Shapes to use the changed description.
2. No more pointers. Although internally the reference will be treated as a pointer for space reasons, keeping it as a non-pointer class is a massive waste of space. Although it is internally stored as a pointer, it won't be treated as so, so it won't be deleted automatically. The problem is now that the reference will be deleted when out of scope, the user who isn't an idiot will know this and use references and pointers accordantly.
I like the "static const Shape::DEFAULT_DESCRIPTION" idea, and will be taking it over to the RigidBody class once my changes to Shape are done. It too has a problem with point 1, with it's creation functions.
I really want NxOgre to be efficient and use less memory as possible.
betajaen
31-10-2009 16:02:34
The more I work on this - the more I want to change the entire Shape system
This is only an idea, and may never be a commit. But I'll explain now.
Basically, Shapes are the odd class in NxOgre. Unlike RigidBodies, Cloths, Fluids, and so on; Shapes have to be created before the actor, then initialised after the Actor with the NxActor as an argument. For this to work, the Shape class (Box, Sphere, Capsule, etc.) takes on two roles.
1. To carry the properties of the shape; size, material, any meshes it may use along with it - to create a NxShapeDesc when needed.
2. To represent a NxShape class to be used after the NxShape has been created and the NxActor is in the scene - I refer to this as attaching.
The problem is here then, that the Shape still carries that extra information once the Shape is attached. In C++ there is no way to resize the class to use less memory, and some of the functions related to the in-use operation of the Shape; getActor, getGlobalPose cannot be used until the shape has been attached. Causing some confusion to the newbies.
What I'm proposing is two make split each shape class into two; Box and BoxDescription. BoxDescription being a reusable class passed by reference that only carries variables and functions related to creating a possible Box in the future, and Box being the single shape representing a NxBoxShape, which is created by the BoxDescription when required. The user creates the BoxDescription, and NxOgre through BoxDescription creates Box.
In code, it may look like this.
mScene->createActor(BoxDescription(1, 2, 3), Vec3(0, 10, 0), ...);
BoxDescription box(1,1,1);
for (unsigned int i=0;i < 10;i++)
mScene->createActor(box, Vec3(0, 0.5f + i, 0);
Box* box = mActor->getShape(0);
The first code snippet, you are passing a reference to a BoxDescription, no more use of the new operator. The second snippet demostrates what is not possible in NxOgre, Once the first Actor is created the Box is attached to it, and any secondary initialisation will cause a crash due to an NxActor with no shapes and the third snippet shows how to get the Box back as a Box once the Actor has been created.
The biggest problem is the API change will effect everyone's code, documentation and tutorials. So a big effort will be required to re-educate everyone and rewrite their code. This will obviously cause some split in the ranks, like now some users still using 0.9 and 1.0
betajaen
01-11-2009 00:18:11
First sub-branch "Bouncer" of Detritus is now at GitHub. I may start doing large commits this way in the future, and merge them back into the parent branch. Anyway the code doesn't compile at all yet - over 400 errors, but most of the Shape classes have been rewritten using the new style.
Like in my previous post, the standard way of creating a shape is now;
Actor* actor = mScene->createActor(BoxDescription(1), Matrix44::IDENTITY);
Multiple shapes are done via ShapeDescription (a stl::vector of ShapeDescription)
ShapeDescriptions descriptions;
descriptions.push_back(BoxDescription(1, 0, Vec3(0,0.5,0)));
descriptions.push_back(BoxDescription(1, 0, Vec3(0,1.5,0)));
Actor* actor = mScene->createActor(descriptions, Matrix44::IDENTITY);
I've added some extra standard features into the ShapeDescription constructor there, a material index and local_pose;
BoxDescription(Real combined_width_height_and_depth = 1, const MaterialIdentifier& material = 0, const Matrix44& local_pose = Matrix44::IDENTITY);
Most ShapeDescriptions have these constructor arguments at the end, so it's a nice extra bonus for those who like inline code - like me.
spacegaier
01-11-2009 02:50:13
Sounds good
.
KyleKatarn
01-11-2009 10:59:05
Sounds great. I've been wary about the BluePrints, and with this it seems much more new-user friendly, while still keeping the functionality that the experienced users like lol.
Keep us updated.
betajaen
01-11-2009 21:09:00
Sounds great. I've been wary about the BluePrints, and with this it seems much more new-user friendly, while still keeping the functionality that the experienced users like lol.
Keep us updated.
My changes are up in the last two commits under the Detritus branch. I had some problems with the git branches, but I think that's sorted out now.
I'll be testing the changes fully in Soy, but Cake uses PlaneGeometries, Spheres and Boxes, so you can assume they at least work. I think the mesh shapes may not work, because I forgot to do something with the userData.
But have a go; see how you like it.
betajaen
02-11-2009 23:28:43
Alright some more changes are up, a much needed saveToDescription functions are added to all shapes for serialisation and the previous commit didn't have a working TriangleGeometryShapeDescription - Now it does.
If your daring, please update to the
[b]latest commit[/b] and see how your app fairs.
waffleShirt
03-11-2009 10:58:51
Out of interest what is the new process for creating a convex object.
I can get as far as loading the mesh from a file, but after that I am not sure how to actualy make the NxOgre::Convex object.
betajaen
03-11-2009 11:01:35
It's explained in this colourful phrase:
Drop the new, append a Description.
mScene->createActor(ConvexDescription(convex_mesh), ....);
joffrey
09-11-2009 02:36:30
Hello,
Bravo for this work.
The VC8 project does not yet exist. Is it planned?
I use that procedure to initialize the git repository:
$ git clone git://github.com/betajaen/nxogre.git
Checking out files: 100% (316/316), done.
$ cd nxogre
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/detritus
remotes/origin/master
$ git checkout remotes/origin/detritus
joffrey
14-11-2009 19:30:14
Hello,
I think another question.
Is it compatible with Ogre 1.7?
nxogre is very nice work !
bybye
betajaen
14-11-2009 19:40:44
If the OGRE API hasn't changed, then yes. I haven't tried it though, although I imagine some people have, and I haven't seen any posts about it not working.
joffrey
14-11-2009 19:53:05
Thank you for your reply.
I will try and tell you.
If I mention the word "Nun", you will add the VC8 project?
betajaen
14-11-2009 20:14:35
Nope, I'll just jump out of my window right now then, in the process of breaking many bones then freeze in this cold weather instead.
[Edit]
I took my iPod Touch with me. I'm very cold now. Thanks for that. <sigh>
joffrey
14-11-2009 20:53:04
I'm sorry.
I did not want to take as many risks.
Sometimes my enflish is bad, i'm from french polynesia where the weather is fine.
joffrey
16-11-2009 22:22:37
compatibility with the application VC8
in the files suffix .vcproj
Line n°4: change Version="9.00" to Version="8.00"
when I compile, I get the same three errors :
c:\nxogre16\nxogre\build\source\nxogremap.h(185) : error C2664: 'std::_Tree<_Traits>::iterator std::_Tree<_Traits>::erase(std::_Tree<_Traits>::iterator)' :
cannot convert parameter 1 from 'std::_Tree<_Traits>::const_iterator' to 'std::_Tree<_Traits>::iterator'
...
my changes in nxogremap.h at lines 180~
before
// Erase a pointer from the map.
void erase(const key_type& key)
{
map_type::const_iterator it = map.find(key);
if (it == map.end())
return;
type_ptr ptr = (*it).second;
map.erase(it);
}
// Erase a pointer from the map.
void erase(const key_type& key)
{
map_type::iterator it = map.find(key); // there
if (it == map.end())
return;
type_ptr ptr = (*it).second;
map.erase(it);
}
When I Compile, I get the following error :
NxOgreOGRE3D_Debug.lib(OGRE3DRenderSystem.obj) : error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: struct std::pair<unsigned long const ,class OGRE3DBody *> const & __thiscall std::_Tree<class std::_Tmap_traits<unsigned long,class OGRE3DBody *,struct std::less<unsigned long>,class std::allocator<struct std::pair<unsigned long const ,class OGRE3DBody *> >,1> >::const_iterator::operator*(void)const " (??Dconst_iterator@?$_Tree@V?$_Tmap_traits@KPAVOGRE3DBody@@U?$less@K@std@@V?$allocator@U?$pair@$$CBKPAVOGRE3DBody@@@std@@@3@$00@std@@@std@@QBEABU?$pair@$$CBKPAVOGRE3DBody@@@2@XZ)
NxOgreOGRE3D_Debug.lib(OGRE3DPointRenderable.obj) : error LNK2001: unresolved external symbol __imp___CrtDbgReportW
C:/ogre1.7/ogre/build//bin/debug/nxogreDemo.exe : fatal error LNK1120: 1 unresolved externals
the error occurs only in debug mode.
release works fine
I use cygwin to compile
file compile.sh
-----
#!/bin/sh
OGRE_HOME="C:/ogre1.7/ogre/build/"
OGRE_SOURCES="C:/ogre1.7/ogre/OgreMain/"
OGRE_DEPENDENCIES="C:/ogre1.7/ogre/Dependencies/"
ACTIVE_CONFIGURATION="debug"
#
#debug options
#NxOgre_Debug.lib
#OgreMain_d.lib
#OIS_d.lib
#NxOgreOGRE3D_Debug.lib
#
runvs8.sh cl /c /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0700" /EHsc /MD /fp:fast \
nxogre_test.cpp /I "$OGRE_SOURCES/include/" /I "$OGRE_HOME/include/" /I "$OGRE_DEPENDENCIES/include/" /I "C:/nxogre/sdk/"
runvs8.sh link /OUT:"$OGRE_HOME/bin/$ACTIVE_CONFIGURATION/nxogreDemo.exe" \
"$OGRE_HOME/lib/$ACTIVE_CONFIGURATION/OgreMain_d.lib" "$OGRE_DEPENDENCIES/lib/$ACTIVE_CONFIGURATION/OIS_d.lib" \
"$OGRE_HOME/lib/$ACTIVE_CONFIGURATION/NxOgre_Debug.lib" "$OGRE_HOME/lib/$ACTIVE_CONFIGURATION/NxOgreOGRE3D_Debug.lib" User32.lib Kernel32.lib nxogre_test.obj
#/NODEFAULTLIB:MSVCRTD
cd "$OGRE_HOME/bin/$ACTIVE_CONFIGURATION/";
"./nxogreDemo.exe";
cd -
file runvs8.sh
#!/bin/sh
tmpfile="/tmp/tmp$$.bat";
echo "@echo off" > $tmpfile
echo "call \"%VS80COMNTOOLS%vsvars32.bat\" >NUL:" >> $tmpfile
echo "bash -c \"%*\"" >> $tmpfile
cmd /c `cygpath -m "$tmpfile"` "$@"
status=$?
rm -f $tmpfile
echo $status
What do you think about that?
[EDIT]
updates applied on my VC++ 2005:
Visual C++ 2005 Express download link
http://go.microsoft.com/fwlink/?linkid=57034
Update SP1 pour Visual C++
VS80sp1-KB926748-X86-INTL.exe (45 MO)
http://www.microsoft.com/downloads/deta ... laylang=en
Correctif SP1 pour Visual C++
VS80sp1-KB971090-X86-INTL.exe (255 MO)
http://www.microsoft.com/downloads/deta ... laylang=en
last edit 11-17-09
joffrey
17-11-2009 17:34:36
Hello again,
I think I reflect poorly but;.
new NxOgre::Box(1, 1, 1)
betajaen
17-11-2009 21:52:40
It's BoxDescription, as told about in the previous page. Obviously your new to Detritus and NxOgre, so you should be using BloodyMess Git. Until Detritus has been officially released.
joffrey
17-11-2009 22:48:05
Thanks for your reply
sorry, my English is bad and I had not read
I see but when it was requested, I chose...
"I'm Awesome!"
instead of
"I want it all ! All the Physics ! All the Works !"
betajaen
17-11-2009 22:49:00
joffrey
18-11-2009 02:10:09
I see but...
I'm not a newbie, I am ... Guybrush Threepwood.
Thx for the link
[EDIT 11-21-09]
BoxDescription works fine on 1.6.0 detritus, thanks Betajaen for your help
I still work with 1.6 hihi
NxOgre::BoxDescription* box;
box = new NxOgre::BoxDescription(1,1,1);
OGRE3DBody* mCube;
mCube = mRenderSystem->createBody(*box, NxOgre::Vec3(0, 40, 0), "../media/models/cube.1m.mesh");
Druha
30-11-2009 15:35:12
Heightfields doesn't work in Detritus
When I try to create one I get an error from here:
void RigidBody::createStatic(const Matrix44& pose, const RigidBodyDescription& description, Scene* scene, const ShapeDescription& shape)
{
RIGIDBODY_EXCEPTIONS_PASS
RIGIDBODY_STATIC_PASS(pose)
RIGIDBODY_SINGLE_SHAPE_DESCRIPTION_PASS(shape) <--- exception from inside of this macro
RIGIDBODY_CREATE_OR_THROW_EXCEPTION
RIGIDBODY_SINGLE_SHAPE_DESCRIPTION_PASS_POST
RIGIDBODY_CREATE_SHAPES_PASS
}
And the error says
Cannot attach a TriangleMeshGeometry or HeightFieldShape shape to a dynamic actor
But what the hell? I didn't even think to do so:
NxOgre::Heightfield hf* = ...
// ...
mMapGeom = PhysManager::getSingleton().getScene()->createSceneGeometry( NxOgre::HeightFieldGeometryDescription(hf,it->second.size));
I need a fix
betajaen
30-11-2009 17:04:46
Alright. I'll try and see what's wrong.
Druha
05-12-2009 20:04:22
I've managed to get heightfield created but when I shutdown NxOgre::World I get error here:
HeightField::~HeightField(void)
{
if (mHeightField == 0)
return;
NxPhysicsSDK* sdk = NxGetPhysicsSDK();
sdk->releaseHeightField(*mHeightField); <-- access violation reading 0x00000000
}
I think about 2 things:
- heightfield was not properly set up ( but objects interact correctly with it )
- heightfield get corrupted during runtime ( but I don't perform any special operatins on it )
But in a lack of knowledge of NxOgre architecture i can't find a reason myself.
Can you give me any tips? May be any places where Heightfields get modified, which are not so obvious?
Here is what I get changed to get them working. I've added these macros instead of those used in RigidBody::createStatic():
#define RIGIDBODY_SINGLE_STATIC_SHAPE_DESCRIPTION_PASS(SHAPE)
NxShapeDesc* shape_description = SHAPE.createShapeDescription();
actor_description.shapes.push_back(shape_description);
#define RIGIDBODY_MULTIPLE_STATIC_SHAPES_DESCRIPTION_PASS(SHAPES)
for (unsigned int i=0;i < SHAPES.size();i++)
{
NxShapeDesc* shape_description = SHAPES[i].createShapeDescription();
actor_description.shapes.push_back(shape_description);
}
betajaen
05-12-2009 20:38:41
Brilliant! That's a start at least.
I'll add your changes in and find out why it's deleting a null pointer after I've fixed these silly errors with the new allocator.
betajaen
06-12-2009 11:35:59
Okay, fixed the errors, and the new memory tracking system seems to be working.
Once I've cleaned up that code, and make the logging file more pretty, I'll investigate your Heightfield problem.
betajaen
07-12-2009 13:18:12
Okay, fixed your heightfield problem:
ManualHeightField mhf;
mhf.begin(4,4);
for (unsigned int i=0; i < 4 * 4;i++)
mhf.sample(100 * i);
HeightField* hf = mhf.end("test");
mScene->createSceneGeometry(HeightFieldGeometryDescription(hf, Vec3(10,10,10)));
Creates the heightfield and deletes it correctly with no crashes or exceptions, it was down the order of deleting the heightfield, actors/scenes.
The new allocator system is reporting some leaks with OGRE3DBodies, so I need to fix that first, and make sure that Detritus works properly in release mode, then I can do a commit.
betajaen
09-12-2009 16:20:52
Okay, my changes are up in the latest commit along with the fix for your heightfield problem. Please try it out and see how it goes.
KyleKatarn
10-12-2009 05:44:54
Well, because our final Project is over, and because Im totally awesome knowing Coco and Ping liek on a personal level, I downloaded the Detrius branch to implement into my wip engine, and it cant seem to find NxOgreMemory.h, when I compile it. Is this cause for worry?
betajaen
10-12-2009 09:56:59
No not really, I just forgot to update the NxOgre.h file when I committed the code, you can remove the offending from there if you like.
Also; Are you the one that keeps leaving strange "meow messages" on our answering machine?
[Edit]
Made the appropriate changes to NxOgre.h. You can either redownload the zip, or have a look at the changelog and see the two lines to remove and the other one to add.
[Edit x 2]
5000th post!!!!!
spacegaier
10-12-2009 10:21:40
[Edit x 2]
5000th post!!!!!
Congratulations! That's my 354th post. But I'll get you
betajaen
10-12-2009 10:43:34
NEVAR!!
deshan
11-12-2009 03:33:44
Congratulations betajaen!!!
Highly appriciate your contribution for the community.
ShUr1k3n
11-12-2009 09:05:27
Is possible to convert the "monkey" from Blender to a Convex?
Because i can only convert it to a Triangles. When i try to convert it to convex i got this output:
------------------------------------------------------------------
MSWindowsFileResource Debug---------------------------
ARI : flour_177619:monkey.flower
Read Ops : 39325
Write Ops : 0
------------------------------------------------------
1
MSWindowsFileResource Debug---------------------------
ARI : flour_177619:monkey.nxs
Read Ops : 0
Write Ops : 0
------------------------------------------------------
Saved monkey.flower as monkey.nxs
and the file size is 0KB. :S
Thanks.
betajaen
11-12-2009 10:02:44
Nope. Too many vertices I think, also the monkey isn't a convex shape anyway.
ShUr1k3n
11-12-2009 10:14:06
Nope. Too many vertices I think, also the monkey isn't a convex shape anyway.
Hum, so its not possible to use it to "walk" around and collide right?
Thanks again betajaen.!
betajaen
11-12-2009 11:17:29
Not physically no; can't move triangle mesh shapes, and it isn't a convex.
You could though match up parts of the monkey using spheres, cubes and capsules and use it like that - That is what your supposed do.
ShUr1k3n
11-12-2009 13:03:08
Oh, ok then. Thanks a lot. Will give it a try.
Keep up your fantastic work!
KyleKatarn
12-12-2009 04:14:13
Hey betajaen,
Thanks for the fix, but it seems to have opened a few more problems. When compiled, I get quite a few errors.
The first error is:
Error 34 fatal error C1083: Cannot open include file: 'NxOgreFileResourceProtocolHeader': No such file or directory c:\cpp-y2\code\visual studio 2008\ogre\legacyengine\dependencies\nxogre\detrius\build\source\nxogreresourcesystem.cpp 29 NxOgre
The line in question contains:
#include NxOgreFileResourceProtocolHeader
Should I assume that the line should be changed to:
#include "NxOgreFileResourceProtocol.h"
And after that error, I get a tonne of errors saying they cant find NxOgre.h
betajaen
12-12-2009 09:03:32
Did you delete the old NxOgre directory? Before replacing it with Detritus? And remember to clean the solution of your application as well.
KyleKatarn
12-12-2009 13:49:12
I thought I had, but it seems I didnt lol. Thanks, works fine.
Druha
12-12-2009 18:09:17
Will I ever see Scene::destroyActor implemented in Detritus ?
[Edit]
And I get many errors during compilation (I am on VS8):
d:\backup\ogre\nxogre\detritus\build\source\NxOgrePtrMultiHashmap.h(223) : error C2664: 'std::_Tree<_Traits>::iterator std::_Tree<_Traits>::erase(std::_Tree<_Traits>::iterator)' : cannot convert parameter 1 from 'std::_Tree<_Traits>::const_iterator' to 'std::_Tree<_Traits>::iterator'
From here:
void erase(const key_type& key)
{
multimap_type::const_iterator it = multimap.find(key);
if (it == multimap.end())
return;
type_ptr ptr = (*it).second;
multimap.erase(it);
Functions::safe_delete<type>(ptr);
}
Looks like there's no multimap::erase(const_iterator& ) method in VC8
Last time when I compile, i just replaced all const_iterator with iterator. Is that solution acceptable ?
betajaen
12-12-2009 21:12:23
Yep. It should be just iterator anyway, because it's a write operation.
I'll do a destroyActor just for you.
betajaen
12-12-2009 21:21:51
Druha
13-12-2009 08:26:12
Oops, sorry, I didn't mention about same errors in NxOgreMap.h and NxOgrePtrHashmap.h
And I think there should be in destroyActor
mActors.erase(actor); // not mActor ;-)
Thanks for "special" edition anyway
betajaen
13-12-2009 10:41:36
Alright, I'll do the special edition with the jet pack addon later then.
betajaen
13-12-2009 19:18:37
ShUr1k3n
14-12-2009 15:07:54
Hello everyone, can any1 tell me if the NxOgre::CylindricalJoint was removed from this new version?
Or was it renamed?
Thanks.
betajaen
14-12-2009 15:12:17
Probably not.
But the D6 joint is in there and it can be any kind of joint. You could use that instead.
ShUr1k3n
14-12-2009 15:39:01
Probably not.
But the D6 joint is in there and it can be any kind of joint. You could use that instead.
Ok, How can i create that joint, there is no scene->createD6Joint(...) , like scene->createFixedJoint(...)
Thanks and sorry for taking your time.
betajaen
14-12-2009 19:35:08
Probably not.
But the D6 joint is in there and it can be any kind of joint. You could use that instead.
Ok, How can i create that joint, there is no scene->createD6Joint(...) , like scene->createFixedJoint(...)
Yes there is:
D6Joint* Scene::createD6Joint(RigidBody* first, const D6JointDescription& = D6JointDescription());
ShUr1k3n
15-12-2009 11:20:19
Probably not.
But the D6 joint is in there and it can be any kind of joint. You could use that instead.
Ok, How can i create that joint, there is no scene->createD6Joint(...) , like scene->createFixedJoint(...)
Yes there is:
D6Joint* Scene::createD6Joint(RigidBody* first, const D6JointDescription& = D6JointDescription());
Ok, its working now. The version that i had was not the right one. Thanks again.
spe02001
21-12-2009 07:19:33
What's wrong in this coding with NxOgre1.6?
NxOgre::Mesh* convexMesh = NxOgre::MeshManager::getSingleton()->load(NxOgre::Path("zip://C:/OgreSDK/media/packs/Box01.zip#Box01.nxs"),"The_Box");
betajaen
21-12-2009 09:48:38
We don't have a zip filesystem in Detritus. It was an example/fictional piece of code.
spe02001
22-12-2009 02:21:01
And also, what's WRONG in THIS CODE IN 1.6??
NxOgre::ResourceSystem::getSingleton()->openArchive("file://C:/OgreSDK/media/nxs/Box01" , "media");
NxOgre::Mesh* convexMesh = NxOgre::MeshManager::getSingleton()->load("media:Box01.nxs");
betajaen
22-12-2009 10:27:36
Can you please read the change log, it has been pointed out a few times that the ResourceSystem doesn't work like that anymore. Go back a few pages in this thread, and you'll see what has changed.
spe02001
22-12-2009 12:44:11
My NxOgre::Path got a error;
EG:
NxOgre::Path path("file://../data/models/cubePhys.nxs");
mprotocol = "file"
mDrive = ""
mFilename = "cubePhys"
mExtension = "nxs"
mPortion = ""
mDirectories = [3](...)
[0] = 0(error)
[1] = 0(error)
[2] = 0(error)
mAbsolute = false
Amnuriak
28-12-2009 15:40:55
Hey there, I worked on a material simulation project from September to Octrobre 09 and had do take a break since then. Just now I have been assigned to update the tools employed in that project, including NxOgre.
I simply got the newest version from Git (1.6x Detri), put it together and ran my app over it resulting in a lot of errors. Apparently, there has been some conceptional changes in NxOgre from what I can tell (which is not much, really).
I used actors with multiple shapes, assigning each shape specified mass values (not necessarily disctinct), meaning those values are more or less arbitrary. Now it appears as if the "new" NxOgreShape class does not have a .setMass() function any longer but instead NxOgreActor has .setMass(). I was (and still am) confused about how this would be and consulted the documentation:
desc.
Set the mass of the Actor
args.
Real __mass__ -- New mass of the Actor
!no_wake
Well, more "?" then "!" for me. One actor has only one mass, independant of shapes ?
I checked this discussion but so far I haven't found anything on this. My question: Was there a conceptional change behind the scenes and where can I find documentation on this ? Most likely, the change spoken of above was not the only one.
NxOgre.org and NxOgre wiki article still only talk about Bleeding and Bloody versions but not about the Detri version. Since I want to be as compatible to future updates as possible, I strongly wish to use Detri and not the older versions.
Thanks,
Amnu
betajaen
28-12-2009 19:11:36
We have had a change of behaviour of the shapes now. It's detailed in the previous pages, and the reason behind it. I haven't made it public outside this thread yet, as Detritus is only for expert users.
Anyway, normally you set the mass of the of the Actor via the RigidBodyDescription, but if needed the BoxDescription, SphereDescription, CapsuleDescription, etc. all should have a "mMass"or "mDensity" properties if you want to have more over the mass local pose. See the PhysX Docs for that bit.
Personally, I would set the mass in the RigidBodyDescription and leave the shape mass stuff alone.
Amnuriak
29-12-2009 09:11:49
Aargh ... I had checked this article for such news but I must have accidently skipped that page. I just checked it again and found it. I wouldn't have asked ... well, sorry
KyleKatarn
30-12-2009 14:05:06
So, will you tell us, the unwashed masses, what clusters are for in the newest commit?
Also, are you planning to implement cloth dynamics into Detrius? And while on that subject, do you think such dynamics would be impractical to have as a persistent element to the player, say a First person perspective game where the player is wearing a robe?
betajaen
30-12-2009 14:37:30
We have cloth, it's in BloodyMess to.
As for Robes. You can certaintly try. In the PhysX documentation there is a page or two explaining chain mail on a PhysX character. I imagine implementing a robe is just as similar.
ahtm80
04-01-2010 21:01:18
hi guys,
nxogre last version contain character control? I scarcely dont work character control. Help me pls. Wait for answers. Thanks.
betajaen
04-01-2010 21:24:39
No, it doesn't.
betajaen
10-01-2010 12:51:31
New Concept Idea
This is an idea I've had for a while now, and I'm going to try it out and see if it works, an experiment of sorts. If it works, I'll leave the code in.
The idea is to split up the Scene class into two variants; Principal and Auxiliary. Principal and Auxiliary are both your normal everyday scenes, both can create RigidBodies that dance around with cloth and fluids. The twist is; Auxiliary can respond to collisions from another Principal scene.
A hybrid of two scenes if you will. Just think, you can offload all your minor special effects such as smoke, pebbles on a beach or street litters to an another scene, freeing up precious resources. You can then tone down the accuracy and processor time for that scene. You can then make a RigidBody's presence known in both scenes; your player character for example. So that the pebbles and street litter move around him, then quickly fall asleep when your hero moves away.
This sort of relationship is only one-way though. If you had a really large pebble for example, on a tree ready to fall on our unsuspecting hero. It would fall on him, but the hero which is a principal-auxiliary RigidBody wouldn't record the impact. Exactly like how Dominance Groups work.
I was going to leave it like that. Everyone would find some good use out of it. But I'm going to take it a step further.
- Principal-Many Auxiliaries. Shouldn't be a problem.
- Principal-Principal. Interesting idea; doubles the NxActor limit. You could even have separate Ogre Root Scene nodes for both Scene's objects, and offset them. Have a bit of Portal/Prey action going on.
Even that is pretty tame. Now who says that the
auxiliary scene should be in the same process as the principal?
Or that a principal could be pre-recorded say? Then played back as a auxiliary?
Those are the things I want.
Druha
20-01-2010 19:57:33
Hi, betajaen!
I am now using Detritus, so I am asking here.
Does NxOgre uses userData property of NxActor? I've seen that with NxShape but haven't with NxActor.
I just want to hold a pointer to my own class there, and think to add some getData()/setData() methods to NxOgre::Actor class
P.S. And I like new scene approach
betajaen
20-01-2010 20:55:12
Yeah, we do.
Why not just inherit from Actor or Body and put your bits in directly? Detritus has a better system now for telling you what type of RigidBody it is now.
rpgplayerrobin
07-02-2010 21:53:12
Hey, I love playing around with this addon, very good work!
But I have a small bug in my application when I upgraded to the new version here (1.6.0 Detrius).
The problem I am having is that when I create a kinematic body and I let the time advance ( m_timeController->advance() ), the kinematic body acts as it has gravity (it falls)...
Before I applied the new version (1.6.0 Detrius) I was using 1.5.5 BloodyMess, and there the kinematic body did not act as it had gravity (it did not fall) when I let the time advance. Is there some kind of a change with this that I should know about?
Here is how I create my kinematic body:
OGRE3DKinematicBody* tmpStaticObjectBody;
tmpStaticObjectBody = m_renderSystem->createKinematicBody( NxOgre::BoxDescription( 15, 1, 15 ),
NxOgre::Vec3( 0, 0, 0 ),
"cube1x1.mesh");
((Entity*)tmpStaticObjectBody->getSceneNode()->getAttachedObject(0))->setMaterialName( "wall" );
tmpStaticObjectBody->getSceneNode()->setScale( 15, 1, 15 );
It shows up correctly, but when I start using m_timeController->advance() it falls...
Any help would be appreciated!
// Robin
EDIT: It seems that if I create a normal OGRE3DBody and let it fall on the OGRE3DKinematicBody, the OGRE3DKinematicBody also seems to be affected by it...
rpgplayerrobin
07-02-2010 22:54:55
Hey, me again!
I used this on the OGRE3DKinematicBody and it worked perfectly, but is it supposed to be like this?:
tmpStaticObjectBody->getNxActor()->raiseBodyFlag( NX_BF_DISABLE_GRAVITY );
tmpStaticObjectBody->getNxActor()->raiseBodyFlag( NX_BF_KINEMATIC );
tmpStaticObjectBody->getNxActor()->raiseBodyFlag( NX_BF_FROZEN );
Cheers,
// Robin
betajaen
07-02-2010 23:10:59
Hi Robin!
Whoops, looks like we have a bug. Your temporary fix is fine, but I'll try and have it a proper solution in the next commit. You can remove the Frozen and Gravity flags though.
retsam
09-02-2010 21:31:36
Just started using this latest and finest shiney new piece of work and already the magic looks nicer than before.
But two things I came up with and I didn't see anything about these so I might as well bother you some more
OGRE3Dbody->getEntity()
What happened to it? but still It's not a big deal to use ->getSceneNode()->getAttachedObject(0); even though it might be a little bit more painful it there's going to be more than one attached object. :/
AngularDamping seems to be somewhat different?
Before my actors were slowing down and went to sleep nicely, but now they keep on "angling" reaaally slow. As if the .mSleepAngularVelocity is not kicking in? Or is this just that I'm setting it in wrong way in OGRE3DRigidBodyDescription since the new shape descriptors are invading our bytes?
betajaen
09-02-2010 23:15:05
getEntity
I took out getEntity(), because you can connect a Camera, ManualObject or something else. Having a getEntity() in those cases would return a NULL pointer, which I don't like, besides you found the Ogre function just fine.
AngularDamping
I haven't changed the RigidBodyDescription/OGRE3DRigidBodyDescription, and they are related to the Shape ones. If you can find out if it's not being given to the NxActor then I may be able to track down the problem. (Try the remote debugger).
retsam
10-02-2010 17:56:37
The angular damping -thing might also be just that the timer code is now different from the one I was using. The animation seems more smooth overall, so it may just be that the framerates and hickups with the old code made it just look different and maybe even perform a bit different with the same values I used. I have to get my project out of my laptop tomorrow to see if I can get any debugger running without crashing
Druha
11-02-2010 13:15:47
Hi, betajaen!
It's me again with container problems.
Here is a fragment from NxOgrePtrMultiHashMap.h
void erase(type* ptr)
{
for (multimap_type::iterator it = multimap.begin(); it != multimap.end(); ++it)
if ((*it).second == ptr)
{
multimap.erase(it);
Functions::safe_delete<type>(ptr);
}
}
After erase method an iterator become invalid and next iteration of "for" loop throws an exception "map/set iterator not incrementable". If this method is intended to erase multiple values at once, I think it should be fixed. Otherwise I'll just add "break" inside the loop to stop it.
betajaen
11-02-2010 14:19:41
Yep, multiple values at once. Must of been half asleep when I wrote that.
break is an easier fix, otherwise a double loop?
Druha
12-02-2010 19:57:22
Looks like a double loop is the only solution for multiple deleting.
tertle
13-02-2010 02:13:05
-edit-
doesn't seem to be an issue anymore
Druha
13-02-2010 13:54:26
Another error I found:
void SweepFunctions::NxSweepQueryHitsToBuffer(NxSweepQueryHit* hits, unsigned int size, SweepQueryHits& buffer)
{
buffer.clear();
buffer.reserve(size);
for (unsigned int i=0; i < size; i++)
{
SweepQueryHit hit;
hit.mDistancePercentage = hits[i].t;
hit.mFaceID = hits[i].faceID;
hit.mHitShape = pointer_representive_cast<Shape>(hits[i].hitShape->userData);
hit.mInternalFaceID = hits[i].internalFaceID;
hit.mNormal.from<NxVec3>(hits[i].normal);
hit.mPoint.from<NxVec3>(hits[i].point);
hit.mSweepShape = pointer_representive_cast<Shape>(hits[i].sweepShape->userData); <--- this line
buffer.append(hit);
}
}
When I use linearOBBSweep funtion to test my rockets for collision I have an Access Violation error from line mentioned above.
hit.mSweepShape as I understand should contain a pointer to Shape object. But linearOBBSweep uses SimpleBox for its calculations which isn't a Shape, so
hits.sweepShape is always null.
[Added]
Looks like RigidBody::getShapes() didn't work, I get complation error when use it:
Map.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class NxOgre::const_ptr_vector_iterator<class NxOgre::Shape> __thiscall NxOgre::RigidBody::getShapes(void)const " (__imp_?getShapes@RigidBody@NxOgre@@QBE?AV?$const_ptr_vector_iterator@VShape@NxOgre@@@2@XZ) referenced in function "private: __thiscall Esertia::Map::Map(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,struct Esertia::Bounds const &)" (??0Map@Esertia@@AAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABUBounds@1@@Z)
Looks like all container classes are not exported so all iterators, types, etc cannot be used outside NxOgre.
I am trying to check whether Shape::getRigidBody is working, because I didn't find any place where NxActor::userData holding a pointer to RigidBody object is set. But maybe I just made some silly mistakes myself
plonga
16-02-2010 17:10:20
Is it possible to use Softbodies now?
I tried creating one in the same way convex bodies are created but it crashed with a NxOgre::DescriptionInvalidException
NxOgre::SoftBodyDescription softDesc;
softDesc.mMesh = NxOgre::MeshManager::getSingleton()->load(NxOgre::Path(meshResource+resString));
NxOgre::SoftBody* soft = mRenderSystem->createSoftBody(softDesc);
Can normal nxs-Files be used for Softbodies?
retsam
18-02-2010 08:41:44
Is there easy trick to do to get collision callbacks working? Any tips on where to look to get it working?
Or is it just me that I can't get them to work on Detritus?
EDIT:
I managed to set it up and running, even though I'm not sure this is the right way?
mScene->getScene()->setUserContactReport(&contactCallback);
After setting this, the volume event is also triggered. Yay!
warkanum
20-02-2010 08:29:47
Hi, I am working on a project I started about 3 months ago ("Gracrux"). It's a stargate simulator, stargates on planets. I got planet render working and my stargates is working nice with nxogre bloodymess.
Now I want to use forcefield to simulate gravity on the planets. I saw that "NxOgreForceField.h" in detritus which I recently switch to and NxOgreForceField.h is empty. Are you going to implement forcefield or is there something wrong that my file is empty.
I saw a few posts about forcefields in earlier versions, didn't see anything in bloodymess though.
Nice work on nxogre by the way
mamairaja
21-02-2010 14:40:46
Please I need Detritus with VS2005 project.
betajaen
21-02-2010 14:52:29
Just edit the sln/vcproj files in notepad and change the version, it's all simple XML files anyway.
It's probably well detailed on Google somewehere.
Druha
21-02-2010 15:12:12
mamairaja
22-02-2010 04:37:21
Just edit the sln/vcproj files in notepad and change the version, it's all simple XML files anyway.
yes that did work
when i compile application(my project with Detritus) i found some errors. Let me try to fix them on my own
betajaen
22-02-2010 10:05:46
Any comments about Shape::getRigidBody() problem, betajaen?
No, I've been busy with
some other projects lately.
So I haven't had a chance to do anything NxOgre related. I would appreciate it though, if any recent bugs found could be submitted to the GitHub tracker, so we have them organised somewhere.
Morrigan
25-02-2010 08:43:37
Hello,
I have a bug with callback after my uptade (bloodymess -> Detritus).
I have :
mScene->getScene()->setGroupCollisionFlag( 1, 1, true );
mScene->getScene()->setActorGroupPairFlags( 1, 1, NX_NOTIFY_ON_START_TOUCH|NX_NOTIFY_ON_TOUCH|NX_NOTIFY_ON_END_TOUCH );
mScene->getScene()->setUserContactReport( this );
To detect collision between object of the same group.
After my update, ALL collision of the scene is detected ... And not only group 1.
Do you have a idea ? It's a error in my code or a bug ? I don't find a fix. I have only a function which call onContactNotify() one time.
And I use only my setGroupCollisionFlag and setActorGroupPairFlags for objet in group 1.
My second problem : I try to create a trigger with mScene->createVolume( triggerDesc, NxOgre::Vec3(position.x, position.y, position.z), this);
but it crash in function createTrigger (NxOgreRigidBody.cpp) line 414 : shape_description->shapeFlags |= collision_type;
What is the good way to create a trigger ?
EDIT: I can't disable collision with NX_IGNORE_PAIR. It cause a crash.
Thank.
rpgplayerrobin
06-03-2010 20:02:09
Hey,
I think I have found another bug:
void OGRE3DRenderSystem::destroyBody(OGRE3DBody* body)
{
if (body == 0 || body->getRigidBodyType() != _OGRE3DBody)
return;
mBodies.erase(body->getNameHash());
}
If you create for example two boxes with the createBody function, you can see that both boxes will have the same hash name (always 0) when you call body->getNameHash(), is this really correct? I am having problems when deleting bodies, that is why I wonder if it is correct...
Cheers,
Robin
EDIT:
I added a temporary function to use instead of the normal destroyBody function:
void OGRE3DRenderSystem::alternativeDestroyBody(OGRE3DBody* body)
{
if (body == 0 || body->getRigidBodyType() != _OGRE3DBody)
return;
mBodies.erase(body);
}
This does work, but it requires you to change the .erase funktion as well, since that is causing a crash, to this:
// Erase a pointer from the multimap then delete it.
void erase(type* ptr)
{
for (multimap_type::iterator it = multimap.begin(); it != multimap.end(); ++it)
if ((*it).second == ptr)
{
multimap.erase(it);
Functions::safe_delete<type>(ptr);
return;
}
}
If this is not done, two objects or more were deleted instead of just one (not exactly sure why, but this fixes it, I am sure it has something to do with the hash name though).
Amnuriak
15-03-2010 16:37:28
Hi there,
I've got a whole bundle of objects of types derived from NxOgre::ShapeDescription. Due to architecture reasons I have to cast them up into NxOgre::ShapeDescription objects, making it necessary to cast them down again - but how ? I can't find any "getShypeType()" which would let me know their derived types. I really don't want to simply try casting them until I get a match (I consider this bad style).
Maybe I'm missing some important aspect of NxOgre's architecture making this obselete but I think this is a "native" approach when dealing with inheritence hierarchies.
Example:
Object A holds all system information (stuff like world, scene, etc.)
Object B is of some base class for simple objects (like a cube)
Object C is a cube class, derived from Class B
User creates C, sets it up and calls it's init() method - which is defined in B. B calls A for actor creation, passing C's shape description as a NxOgre::ShapeDescription object - since it can't know whether it has been called with a BoxDescription, a CapsuleDescription, ...
Now apparently, scene's createActor method won't accpet base class shape description objects - always breaks the app - allowing only derived types, e.g. BoxDescription but ShapeDescription doesn't have any mechanism to cast the shape description object back into its derived type -> Problem.
Edit:
Another question: How do I tell NxOgre which Ogre Mesh it shall use for a specific body ? In Bloody the createActor method required one to supply the name of the mesh but now there's no such thing. I suppose ShapeDescription::mSkeleton is the right thing but MeshManager::getByName("someOgreMeshName") won't work - or is that right and I'm screwing up in yet another place ?
Druha
15-03-2010 20:18:57
As far as I know, NxOgre doesn't deal with .mesh files anymore in Detritus
Amnuriak
16-03-2010 07:52:06
Edit:
DOH! Forget about my mesh question. Shouldn't have gotten up that early ...
Regarding my first question:
I realize I could simply implement my desired functionality by inheriting from or aggregating the appropriate classes and that's exactly what I'm doing right now. But looking at how neatly everything fits (or is supposed to fit
) inside NxOgre I wonder why there is no way to cast ShapeDescriptions down from their base class to enable more flexibility for external applications/frameworks when dealing with automatic actor/shape creation.
betajaen
16-03-2010 10:08:13
The Shape system isn't really designed to be inherited by the user, like Actors are. I'm afraid.
If you can make it work go ahead; but when you pass on a ShapeDescription to an Actor constructor (or creator method), it expects a reference, and you can't cast references.
Thrakbad
28-03-2010 14:47:48
So I just noticed that my callback for volumes isn't triggered any more with Detrius, althought the code compiles fine and it worked perfectly in Bloody Mess. Have there been changes to the volume system? How do I get it working again?
Amnuriak
06-04-2010 12:39:11
Trying to get simple actors with multiple shapes up and running is causing some confusion.
ShapeDescriptions descriptions;
BoxDescription boxDesc;
boxDesc.mSize = Vec3(2, 2, 2);
boxDesc.mLocalPose = Matrix44(Vec3(0, 4, 0));
descriptions.push_back(boxDesc);
scene->createActor(descriptions, Matrix44::IDENTITY);
will cause
// NxShapeDesc.h
NxShapeType getType() const { return type; }
to jump at me.
BoxDescription boxDesc;
boxDesc.mSize = Vec3(2, 2, 2);
boxDesc.mLocalPose = Matrix44(Vec3(0, 4, 0));
scene->createActor(boxDesc);
This works fine so I doubt the error to be with the surrounding code - scene setup, etc. I tried to step into the code but it will only let me see
RigidBodyDescription::RigidBodyDescription(void)
{
reset();
}
before the exceptions jumps me. I considered supplying some dummy rigid body description so that code isn't called in the actor's setup function chain but it IS called earlier so that can't be the source of the problem either.
betajaen
06-04-2010 12:49:54
Do'h, I'm stupid.
I can see the problem now.
Try this:
Go into NxOgreShape.h and change:
typedef std::vector<ShapeDescription> ShapeDescriptions;
to
typedef std::vector<ShapeDescription*> ShapeDescriptions;
Then in NxOgreRigidBody.cpp, replace
NxShapeDesc* shape_description = shapes[i].createShapeDescription()
with
NxShapeDesc* shape_description = shapes[i]->createShapeDescription()
There should be four of them, and compile NxOgre.
You have to pass your ShapeDescription as a reference then.
I think it goes:
descriptions.push_back(&boxDesc);
(Or perhaps)
descriptions.push_back(*boxDesc);
See if it works then.
Amnuriak
06-04-2010 13:34:13
Seems to be working, thanks
I have yet to use more complex shaped actors but it would make sense they also work fine.
The only "ugly" thing about this solutions is
BoxDescription boxDesc;
vs.
BoxDescription* pBoxDesc = new BoxDescription();
Might be kind of picky but I consider this to be inconsistent - using a reference in the simple case while using (a vector of) pointers in the compound case. I'm not complaining though - just my humble opinion.
PS: Yey ! It wasn't my fault !
betajaen
06-04-2010 14:20:43
There is no need for a "new", you should be able to pass it on as a reference as long as you stay in scope.
BoxDescription desc;
ShapeDescriptions.push_back(&desc);
Amnuriak
06-04-2010 14:45:59
I know there's no need for the "new" but whenever I have to work with addresses I prefer using pointers, even if it means having to delete them afterwards. Just a (bad) habit of mine.
The thing I was talking about is the difference in function signature between constructing a "simple" actor and a "compound" one. One time one has to pass a concrete object reference while the other time the API expects an object's address. I'm being picky, I know
As I said I'm not complaining, just trying to point at a - imho - inconstistency with the rest of the framework.
betajaen
06-04-2010 15:57:59
PhysX does it the same way too.
NxSphereShapeDesc sphereDesc;
sphereDesc.radius = 1.0f;
actorDesc.shapes.pushBack(&sphereDesc);
Where shapes is a:
NxArray< NxShapeDesc *, NxAllocatorDefault >
Without using a pointer, your only copying the parent class and not the derived one; making the whole point of inheritance useless. The alternative solution is to merge Box,Sphere,Convex,Triangle,HeightfieldDescriptions all into one massive memory hogging class.
Also; if you use "new". NxOgre doesn't know you new'd it, and your leaving an pointer there.
Amnuriak
07-04-2010 15:30:55
How can I make a dynamic actor ignorant to collisions ? Usually I'd call something like
NxActor::raiseBodyFlag(NxBodyFlag::NX_BF_FROZEN)
or
NxActor::raiseBodyFlag(NxBodyFlag::NX_BF_KINEMATIC )
but I can't find it. Where did I not look ?
Druha
08-04-2010 07:05:10
Look at RigidBodyDescription - there are mActorFlags and mBodyFlags. Actual values for them can be found at NxOgre::Enums namespace
Amnuriak
08-04-2010 14:48:48
Ah there it is, thanks
And here's the next one ... I can't seem to find a hint at whether CCD has been implemented in Detritus. Currently I have dynamic actors "being pushed" through by other dynamic actors (but not through kinematic actors which I use as a workaround). I figure at some point the forces pushing the actors become so large that their estimated velocity after being "pushed" by the forces becomes so high the next simulation step the actors are beyond collision detection areas. At least that's the only reason coming to my mind after having increased object sizes as well as the cube's "wall thickness" and having switched dynamic cube actor with a kinematic one. So what's the status with CCD ?
betajaen
11-04-2010 15:56:32
Detritus/Nonrigid
- Switched to Pasta to generate project files
- Split OGRE3DRenderSystem into seperate project; see
http://github.com/betajaen/critter
- Removed OpenGL render system - will be forked into a seperate project in
the future.
- Added many string functions; to_s, to_i, to_f and Strings namespace
functions.
- Added contains and replace functions to Buffer
- Added prototype Character Controller classes. DOES NOT WORK.
- Renamed MeshSerialiser to NXS
- Added Flower load/save to Serialisation namespace.
- Added prototypes for Scene linking
- Added writeString to resource
- Added helper class TextResourceStream
- Added Radian class.
- Added MeshData constructor, setVertex and scaleVertex to ManualMesh
- Added map and vector functions; see Maps and Vectors namespaces.
- Added getTypeAsString to Mesh
- Fixed bug with ShapeDescriptions.
- Added String constructor, isNegative, to_s and to_a to Vec3
- Removed Soy.
Amnuriak
12-04-2010 09:02:06
Strange - posted a message and it went down the sink ... Oh well, it's monday.
Just downloaded new release and prebuild script failee.
Error 1 Error result 1 returned from 'C:\WINDOWS\SysWow64\cmd.exe'. Project NxOgre
Doesn't surprise me since "vc.prebuild.bat" has 0 byte size - nothing will happen there. I downloaded again - just making sure nothing broke in the process - but same result. Did you intend to put something in there ?
Skipping the prebuild event, everything seems to be working fine.
betajaen
12-04-2010 09:25:48
No, it's meant to be blank.
I'm surprised it failed on that bit, my Visual Studio had no problems with it. Perhaps if I put a comment in, it may work for you.
Amnuriak
12-04-2010 09:29:59
Well, I figured it was a placeholder for future stuff so I just skipped the prebuild event. Worked fine but I got issues with critter now. Might I have missed you announcing an update to ogre 1.7 ? From the attempted includes I figure this to be the case.
betajaen
12-04-2010 09:32:07
Yeah, I use it increase the version build number and generate a new name for the commit.
As for Critter; Yep, it uses the Ogre 1.7.0 style includes now. I wished they kept it to the old versions; I preferred that. Oh well.
Amnuriak
12-04-2010 10:20:59
Updated to PhysX 2.8.3 and apparently there's been a slight change in names. What appears to have been "NxCooking.lib" is now "PhysXCooking.lib". After the linker failed looking for NxCooking.lib it worked fine with PhysXCooking.lib. Going to see if it works now.
Edit:
It appears as though NxOgre can't launch physX.World::createWorld() will complain about physX sdk not being installed - even though it's there and the path is set. Oh and I had to copy PhysXLoader.dll to my working directory (which I can't remember to have done in the past, so that's kinda new).
betajaen
12-04-2010 10:36:34
Updated to PhysX 2.8.3 and apparently there's been a slight change in names. What appears to have been "NxCooking.lib" is now "PhysXCooking.lib". After the linker failed looking for NxCooking.lib it worked fine with PhysXCooking.lib. Going to see if it works now.
Edit:
It appears as though NxOgre can't launch physX.World::createWorld() will complain about physX sdk not being installed - even though it's there and the path is set. Oh and I had to copy PhysXLoader.dll to my working directory (which I can't remember to have done in the past, so that's kinda new).
That is new, I've been on 2.8.1 for a long time now and I haven't bothered to upgrade. Why change it all anyway? It was perfect as it was.
Anyway, I'll have to modify nxogre.pasta for the new name, and regenerate the project files. That will be in the next commit.
Amnuriak
12-04-2010 10:39:38
I tried to fix
this problem by upgrading to a newer sdk and vrd version. I suppose since you did not develop with/test against 2.8.3 NxOgre will not work with it. So far World::createWorld() will fail, complaining it cannot find the SDK ("PhysX SDK not installed"). Trying to find the problem right now.
betajaen
12-04-2010 10:46:04
I tried to fix this problem by upgrading to a newer sdk and vrd version. I suppose since you did not develop with/test against 2.8.3 NxOgre will not work with it. So far World::createWorld() will fail, complaining it cannot find the SDK ("PhysX SDK not installed"). Trying to find the problem right now.
I'm upgrading too.
I'll try and find the cause of your VRD problem later today; I have a theory.
[Edit]
Compiling NxOgre now. Heh, they have 64-bit version of the libs now.
betajaen
12-04-2010 11:03:01
[attachment=0]screenshot04122010_112544200.jpg[/attachment]
Okay, compiled NxOgre, Critter and the secret Tutorial 103 (which you guys aren't supposed to know about yet). It works fine, I did have to upgrade the SystemSoftware though (you can check by launching one of the PhysX samples to see if crashes or not. Mine did, so I upgraded and no longer crashes) and I also didn't need to copy the PhysxLoader.dll into my application folder either.
I did have this in the log.
Warning (PhysXOutputStream)
===========================
PhysX warning:
Upgrade to NVIDIA GeForce 196.21 or later driver to enable GPU PhysX
NxErrorCode:Warning
From: ..\source\NxOgrePhysXOutputStream.cpp#74
But I haven't upgraded my drivers in a while, so that's my bad.
betajaen
12-04-2010 12:08:42
Detritus/Earthkin
- Upgraded project files to PhysX 2.8.3
- Fixed flower triangle mesh bug.
Amnuriak
12-04-2010 14:02:46
Well, this little upgrade had one heck of a rat's tail ...
Upgrade PhysX/VRD -> Upgrade NxOgre -> Upgrade to Critter -> Upgrade to Ogre1.7 -> Upgrade App ... Basically upgrading everything. I'm not exactly happy but what's due must be taken care of ...
Thank's for the info, I'll try to make the best of it.
betajaen
12-04-2010 14:23:17
You can use Ogre 1.6.0 with Critter; you'd just have to change the include paths.
Oh, well, everything is new and shiny now.
Amnuriak
12-04-2010 14:46:21
No matter what I do I keep getting the strangest errors. Would you mind sharing a sample application using 1.7 ? Actually, I'm not fired up about neat graphics just about getting things running again. I'll use the VRD to debug my objects anyway.
betajaen
12-04-2010 16:15:20
I wrote this program for you.
All it does is creates NxOgre/PhysX, cooks a convex mesh, creates an actor for it and runs the simulation until the VRD program is closed. In memory allocation terms it's quite extensive; cooking a mesh requires a number of allocations and deallocations, then you have the usual NxOgre overhead.
Just copy and paste into a blank application; link/include to NxOgre and run the VRD then run it. With any luck you should see a spinning pyramid on the screen. Hopefully you will be able to track any leaks.
#include "NxOgre.h"
using namespace NxOgre;
void physics()
{
World* world = World::createWorld();
std::cout << "** Started.\n";
Scene* scene = world->createScene();
ManualMesh mm;
mm.begin(Enums::MeshType_Convex);
mm.vertex(-1,0,-1);
mm.vertex( 1,0,-1);
mm.vertex( 1,0, 1);
mm.vertex(-1,0, 1);
mm.vertex(0, 1, 0);
Mesh* mesh = mm.end();
Actor* actor = scene->createActor(ConvexDescription(mesh));
actor->addLocalTorque(Vec3::random(50,-50,50,-50,50,-50));
RemoteDebugger* debugger = world->getRemoteDebugger();
TimeController* timeController = TimeController::getSingleton();
debugger->connect();
if (debugger->isConnected())
{
std::cout << "Gained connection, simulating. Close the VRD to stop the program.\n";
Timer timer;
float progress = 0.f;
while(debugger->isConnected())
{
if (timer.now() > _1_60)
{
progress += timer.now();
timer.reset();
timeController->advance();
if (progress > 1.f)
{
std::cout << ".";
progress = 0.f;
actor->addLocalTorque(Vec3::random(50,-50,50,-50,50,-50));
}
}
}
std::cout << "\nLost connection.\n";
}
else
{
std::cout << "No connection found. Start the VRD.\n";
}
World::destroyWorld();
}
void main()
{
physics();
std::cout << "** Stopped.\n";
}
Amnuriak
14-04-2010 12:24:44
Got it all up and running again. Works just fine, thanks for the support
New VRD is not causing leaks anymore though it's still eating up memory like crazy. Guess the calculations are quite expensive but I won't investigate unless there are leaks again.
betajaen
14-04-2010 12:26:35
Is there anyway to trace the leaks? If it comes from NxOgre or PhysX?
I mean can you write a small application just using PhysX with the VRD and see if that is causing a leak?
Amnuriak
14-04-2010 14:06:40
I'm pretty sure the leaks were not coming from NxOgre but from PhysX/VRD. I can't tell for sure where they came from but the leaks only occured while running the VRD - only launching a simulation did not trigger the leaks. That's pretty strong evidence for some bug in the older version, though it might have been triggered by some exotic parameter setup. Can't reproduce that anymore so that's all I can tell.
rusekpawel
14-04-2010 16:08:24
Hello, It's my first post on this forum
I'm using NxOgre for a short time and I'm not familiar with it so good, but I know i must use detritus because of variable time step and not working argument in TimeController::Advance method.
Anyway I was trying to load build with flour nxs file. In BloodyMess everything was OK, here I get runtime exception: NxOgre::IOException on line:
NxOgre::ResourceSystem::getSingleton()->openArchive("file:media", "media");
where media folder is in working directory of my project.
Here is full code:
#include "ExampleApplication.h"
#include <NxOgre.h>
#include <NxOgreOGRE3D.h>
class BloodyMessTutorial2Listener : public ExampleFrameListener
{
public:
BloodyMessTutorial2Listener(RenderWindow *win, Camera *cam)
: ExampleFrameListener(win, cam)
{
mTimeController = NxOgre::TimeController::getSingleton();
}
bool frameStarted(const FrameEvent& evt)
{
mTimeController->advance(evt.timeSinceLastFrame);
return ExampleFrameListener::frameStarted(evt);
}
protected:
NxOgre::TimeController* mTimeController;
};
class BloodyMessTutorial2 : public ExampleApplication
{
protected:
NxOgre::World* mWorld;
NxOgre::Scene* mScene;
Critter::RenderSystem* mRenderSystem;
Critter::Body* convexBody;
void createScene()
{
// Set ambient light
mSceneMgr->setAmbientLight(ColourValue(0.5f, 0.5f, 0.5f));
// Create a light
Light* l = mSceneMgr->createLight("MainLight");
l->setPosition(20, 80, 50);
// Position the camera
mCamera->setPosition(0, 20, 80);
mCamera->lookAt(0, 20, 0);
mCamera->setNearClipDistance(0.01f);
mWorld = NxOgre::World::createWorld();
NxOgre::SceneDescription sceneDesc;
sceneDesc.mGravity = NxOgre::Vec3(0, -9.8f, 0);
sceneDesc.mName = "BasedOnBloodyMessTutorial2DetritusScene";
mScene = mWorld->createScene(sceneDesc);
mScene->getMaterial(0)->setStaticFriction(0.6);
mScene->getMaterial(0)->setDynamicFriction(0.6);
mScene->getMaterial(0)->setRestitution(0.3);
mRenderSystem = new Critter::RenderSystem(mScene);
convexBody = NULL;
Critter::Body* mCube;
mScene->createSceneGeometry(NxOgre::PlaneGeometryDescription());
MovablePlane *plane = new MovablePlane("Plane");
plane->d = 0;
plane->normal = Vector3::UNIT_Y;
Ogre::MeshManager::getSingleton().createPlane("PlaneMesh",
ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME,
*plane, 120, 120, 1, 1, true, 1, 3, 3, Vector3::UNIT_Z);
Entity *planeEnt = mSceneMgr->createEntity("PlaneEntity", "PlaneMesh");
planeEnt->setMaterialName("Examples/GrassFloor");
Ogre::SceneNode* mPlaneNode = mSceneMgr->getRootSceneNode()->createChildSceneNode();
mPlaneNode->attachObject(planeEnt);
mPlaneNode->scale(100, 100, 100);
NxOgre::ResourceSystem::getSingleton()->openArchive("file:media", "media");
NxOgre::Mesh* convexMesh = NxOgre::MeshManager::getSingleton()->load("media:hullKostki.nxs");
NxConvexMesh* cm = convexMesh->getAsConvex();
NxOgre::ConvexDescription* sd = new NxOgre::ConvexDescription(convexMesh);
convexBody = mRenderSystem->createBody(*sd, NxOgre::Vec3(0, 30, 0), "kostka.mesh");
convexBody->setGlobalOrientation(NxOgre::Matrix33(NxOgre::Quat(0, 45, 0, 45)));
convexBody->setMass(20.0f);
convexBody->addForce(NxOgre::Vec3(-5000.0f,0.0f,-5000.0f));
}
// Create a new frame listener
void createFrameListener()
{
mFrameListener = new BloodyMessTutorial2Listener(mWindow, mCamera);
mRoot->addFrameListener(mFrameListener);
}
};
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
#define WIN32_LEAN_AND_MEAN
#include "windows.h"
#endif
#ifdef __cplusplus
extern "C" {
#endif
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
INT WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT)
#else
int main(int argc, char **argv)
#endif
{
// Create application object
BloodyMessTutorial2 app;
try {
app.go();
} catch(Exception& e) {
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
MessageBoxA(NULL, e.getFullDescription().c_str(),
"An exception has occurred!", MB_OK | MB_ICONERROR | MB_TASKMODAL);
#else
std::cerr << "An exception has occurred: " << e.getFullDescription();
#endif
}
return 0;
}
#ifdef __cplusplus
}
#endif
and sorry for my English, I'm from Poland.
betajaen
14-04-2010 16:35:27
It is best not to use archives in detritus anymore.
Just use relative or absolute paths to your resources for now.
i.e.
NxOgre::Mesh* convexMesh = NxOgre::MeshManager::getSingleton()->load("file://media/hullKostki.nxs");
rusekpawel
14-04-2010 16:40:05
Yuppi!
Betajaen... if i could... I would kiss your brain.
Everything works fine now.
Cheers
betajaen
14-04-2010 18:55:38
This is my idea for replacement for Archives - "aliases".
Create an alias:
Path::AddAlias("game", "file://c:/Program Files/My Game/");
Then use it:
MeshManager::getSingleton()->load("+game/mesh.nxs");
rusekpawel
14-04-2010 21:09:03
NxOgre::Path does not seems to have AddAlias method. Are you planning to add this in next release? I think it would be a good idea.
I got few other simple questions:
1) does TimeStepMethod_Variable working? My object acting strange (dissapears?!).
2) can I use default TimeStepMethod_Fixed and pass to advance method my timeSinceLastFrame to ensure that physics speed will act the same on diffrent system configurations (slow PC, fast PC)
3) silly question: will NxOgreOGRE3D.h be removed in further release of Critter?
betajaen
14-04-2010 21:58:54
NxOgre::Path does not seems to have AddAlias method. Are you planning to add this in next release? I think it would be a good idea.
I got few other simple questions:
1) does TimeStepMethod_Variable working? My object acting strange (dissapears?!).
2) can I use default TimeStepMethod_Fixed and pass to advance method my timeSinceLastFrame to ensure that physics speed will act the same on diffrent system configurations (slow PC, fast PC)
3) silly question: will NxOgreOGRE3D.h be removed in further release of Critter?
Next commit most likely. I've wrote the code, testing it now.
1. Sort of. You should use a fixed timer. Variable timers are unpredictable.
2. The Timestep is fixed, it uses it's own internal timing. Your supposed to advance it every ~1/60 of a second, but it uses it's own timing code for high precision. They should act the same rate on a slow or fast PC.
3. Not until the dust has settled.
rusekpawel
14-04-2010 22:24:46
the reason why i would not like to use default _1_60 = 0.0166666f in advance argument is that my animation runs then in sort of slow motion. In my other application where NxOgre isn't used - just PhysX - i gets the same result: slow motion. Maybe it's because i have ATI graphics card so calculations are done with CPU. Any suggestions how to spead up my animation whitch would act the same on diffrent PC's?
spacegaier
14-04-2010 22:54:39
Not sure if I understood you correctly, but in general - if you want to have things moving at the same speed on differently strong PCs - is to multiply all movements with the time since the last frame.
rusekpawel
14-04-2010 23:04:25
That's generally true, but I let PhysX take care of moving my objects so speed should be only determinated by gravity (when falling) forces and mass of objects (when there are collisions). The only one place when I can change this is advance method when i tell PhysX how much time i want to pass in animation... Maybe it's not clear, check out
this link. My problem is that in Fixed time step i should not change advance argument, and in Variable TimeStep there are crazy things happens.
I'm quite newbie in physx engines so i may be totally wrong about it. (should I open new thread for this problem?)
betajaen
14-04-2010 23:22:52
Leave it be. Just advance time every 1/60 of a second as best you can, the NxOgre and PhysX will calculate the correct timestep for you.
betajaen
15-04-2010 19:38:11
Detritus/Bedrop
- Removed Archives
- Added Aliases in paths
As there is an API change with the removal of Archives, I've replaced it with aliases.
Briefly. Aliases work with Paths, basically they substitute part of the string with another.
Path::SetAlias("test", "file://media/");
Path path("+test/mesh.nxs");
Is shorthand for:
Path path("file://media/mesh.nxs");
Aliases all follow the same route:
+aliasname/rest of the path goes here
spacegaier
15-04-2010 20:34:32
Some smaller fixes had to be done, but now in
Detritus/Grabber it's definitely working
.
betajaen
16-04-2010 12:49:20
Brakok
20-04-2010 23:53:45
Hi, I got errors when compiling Critter. I dunno if it my versions that are incompatible or me that made a mistake when linking things to Critter project, but when I try to compile, errors returned are:
Error 1 error C2888: 'void NxOgre::Functions::safe_delete(type *)' : symbol cannot be defined within namespace 'Critter'
SolutionDir\nxogre\detritus\critter\build\source\CritterBody.h 60
Error 2 error C2888: 'void NxOgre::Functions::safe_delete(type *)' : symbol cannot be defined within namespace 'Critter'
SolutionDir\nxogre\detritus\critter\build\source\CritterKinematicBody.h 46
Note: When I write SolutionDir, it's only to hide my computer files, not that they are in the same folder.
My project use Ogre 1.7 and NxOgre Detritus last release (9fcf62b). Do you know how I can build critter? Thx for any advice.
Amnuriak
21-04-2010 09:06:15
I just downloaded newest version of Critter and NxOgre after reading your post and it compiled just fine. My guess would be your Critter project contains an include/dependency path like "$(NXOGRE_DIR)\SDK" and that value still points to the "old" version. In case of doubt just set all paths to absolute values pointing to the sources.
betajaen
21-04-2010 09:10:17
You should also delete the old NxOgre/Crittier directories if your replacing it with a newer version.
I've been caught out with that a few times; hence the odd updates on Git.
Amnuriak
21-04-2010 11:54:57
PhysX documentation states NxScene::setShapePairFlags(NxShape&, NxShape&, NxU32 flags); as a means of disabling collision detection on shape level, e.g. when disabling collision of shapes within the same actor.
I can't find an equivalent with NxOgreScene nor with NxOgeShape. There is a NxOgreShape::setFlag() and NxOgre::Enums::ShapeFlags_ShapeFlags_NoCollision but this works as a general collision avoidance - where I only want speficic shapes to not be able to collide with each other.
Where can I find this in Detritus?
Brakok
22-04-2010 01:40:09
Just to end my problem with Critter (in hope that nobody never do this error again):
The c2888 error raised by the project is a compiler error in MVS 2005. Then don't use MVS 2005 to compile it... Critter builds just fine on VC++ 2008.
Edit: Argh, can't even works on MVS 2005. Include Critter raises c2888...
Brakok
27-04-2010 00:29:37
Hi, i tried for some times now to make visualDebugger works on my project. I assume that it's not the visualDebugger that doesn't work, because someone already posted in this thread that it works better than in BloodyMess.
Each time i start my project with the VisualDebugger on, it raises the error:
Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
My code to initialise the VisualDebugger:
visualDebugger = world->getVisualDebugger();
renderable = new Critter::Renderable(NxOgre::Enums::RenderableType_VisualDebugger);
visualDebugger->setRenderable(renderable);
visualDebuggerNode = ogreScene->getRootSceneNode()->createChildSceneNode();
visualDebuggerNode->attachObject(renderable);
visualDebugger->setVisualisationMode(NxOgre::Enums::VisualDebugger_ShowAll);
I searched in Ogre Forums to see if it was not an error of the renderer, and i saw that in most case it's due to
conflicts between old and new version of Ogre.
But my error raises only when i tried to put the visualDebugger into my project. That's why i post it here in hope
that someone knows something about it.
I already tried to rebuild Ogre 1.7 and NxOgre 1.6, but it didn't help.
Thx for any advice or hint (or solution).
Edit: for the moment, i use the PhysX VisualDebugger application, but even rebuilding ogre or go ahead with ogre 1.7.1 raises the error as described sooner.
betajaen
04-05-2010 18:27:16
Detritus/Outliver
- Replaced some description classes with automatically generated ones.
- Added automatic flag classes.
- Added flag functions to RigidBody and Actor.
- Fixed Wheel Shape crash
- Removed Array class
- Added "Vector" class.
- Rewrote TimeController class and functions
- Added LinearInterpolationMap class
I recommend everyone who is using Detritus to upgrade to this commit.
- Scene simulations seems a lot more stable now due to the new SceneDescription and TimeController code.
- Wheels do not crash when you use them!
- Last of the old array code is out. It's all STL now!
Karan
05-05-2010 19:47:36
With that commit I get errors in Critter, CritterKinematicBody.h:45 because of the missing ArrayFunctions. When I remove that line everything works (but I don't use kinematic bodies).
betajaen
05-05-2010 19:50:32
Ahh. Thanks for mentioning that.
I'll do commit for Critter then.
Karan
06-05-2010 17:41:09
Found a little typo: FluidDescription.mRestParticlesPerMetre
betajaen
06-05-2010 18:25:47
I'm British, we spell Metre the proper way.
Karan
06-05-2010 18:58:20
The PhysX API uses meter, so it's wrong no matter where you're from
rusekpawel
06-05-2010 23:15:57
And you are using NxOgre witch uses Betajaen's API so I think he chooses how should everything be named.
Sorry for spam/trolling. I just couldn't resist.
Cheers, Pawel Rusek.
betajaen
06-05-2010 23:34:29
Exactly!
And if I want to misspell class names on purpose, then I have the right to do so!
Karan
14-05-2010 21:22:56
This time I found a real bug: in the FluidEmitter constructor this line is missing: ed.rate = description.mRate;
(Currently you can only adjust the rate with FluidEmitter::setRate(), not with a FluidEmitterDescription).
betajaen
14-05-2010 21:39:17
Thanks!
Karan
20-05-2010 15:23:59
Either there's something wrong or I just don't get how to handle your shared pointer:int particleCount = *mFluid->getParticleData()->mNbParticles.get();
This gives me a linking error:
Error 1 error LNK2019: unresolved external symbol "__declspec(dllimport) public: unsigned int * __thiscall NxOgre::SharedPointer<unsigned int>::get(void)const " (__imp_?get@?$SharedPointer@I@NxOgre@@QBEPAIXZ) referenced in function __catch$?updateFrameStats@OgreWidget@@AAEXXZ$0 OgreWidget.obj
I just want to get the current number of particles^^
betajaen
20-05-2010 16:00:19
I had a large post up here explaining how to fix it - turns out I was wrong. I'll get back to you.
betajaen
20-05-2010 22:46:42
Urgh, sorry about that. I'm having troubles with Fluids myself.
Basically your way isn't going to work - due some code I didn't write. I can't test this, but try adding these to the Fluid class.
NxOgreFluid.h
/** \brief
*/
unsigned int getNbParticles() const;
NxOgreFluid.cpp
unsigned int Fluid::getNbParticles() const
{
return mParticleData->getNbParticles();
}
Karan
21-05-2010 20:12:40
Thanks, it works
And it helped me debug another more serious issue: When the particle count goes beyond ~16384, the Ogre particle system doesn't render the particles properly anymore - old particles start to disappear in strange cubically formed areas, see screenshots:
Screenshot 18k particles
Screenshot 21k particles
Do you have an idea what might cause that? Could the Ogre particle system have an undocumented limitation to 16k particles? I had a quick look at your code in CritterParticleRenderable.cpp and it seemded ok...
By the way, what kind of troubles with Fluids do you have?
betajaen
21-05-2010 21:33:48
Can't see your images; invalid permissions I'm afraid.
I have serious serious lag on 25k particles; regardless on the type of renderable. I'm not sure why, I can't see any bottlenecks. It's the same code as before, but I am in debug mode which to be fair -- Isn't the fastest thing in the world.
Basically; I've rewritten
all of the container system, all the memory allocation, new/delete overrides, and added a memory debugger system, pretty much affecting all of NxOgre. So there is bound to be some slip ups.
Fluids seems to be fixed now, anyway. Now I have a weird problem with the FileResource class, urgh.
[Edit]
It isn't clear in the documentation but perhaps there could be a particle limit of 16k per fluid in PhysX?
[Edit x2]
Oh, I forgot. I removed the TimeController in favour of something more flexible. I'll be making a big post about the new replacement soon, it will even come with diagrams, and there will be free coffee and cake.
Karan
21-05-2010 22:34:52
Oops, I thought testing the links in a different browser should be enough, but apparently not....
this one works hopefully though.
What kind of lag do you mean? With the position renderable I get around 900fps at the start - then it steadily decreases with the increasing number of particles. At around 42k particles it drops below 60fps and at 65535 (which is the PhysX maximum) it's still 14fps (I have a GTX 260 by the way).
The rendering problem only occurs with the Ogre particle system (and I need the quads for the advanced fluid surface rendering technique I'm implementing).
EDIT: with the Ogre particle system the framerates are quite a bit slower, but at 30k particles it's still around 50fps.
betajaen
21-05-2010 22:45:47
Oops, I thought testing the links in a different browser should be enough, but apparently not....this one works hopefully though.
What kind of lag do you mean? With the position renderable I get around 900fps at the start - then it steadily decreases with the increasing number of particles. At around 42k particles it drops below 60fps and at 65535 (which is the PhysX maximum) it's still 14fps (I have a GTX 260 by the way).
The rendering problem only occurs with the Ogre particle system (and I need the quads for the advanced fluid surface rendering technique I'm implementing).
EDIT: with the Ogre particle system the framerates are quite a bit slower, but at 30k particles it's still around 50fps.
About 0.2 FPS, and we have the same graphics card.
I am using the OgreSamples framework though with the new NxOgre Tutorials I'm working on. So it's using all those shadow shaders and fancy materials that I don't understand, and it's in debug mode.
Perhaps those particles have died and they have been cleaned up. You compare it against the VisualDebugger.
False alarm on that file error. Turns out my new CCD skeleton code has a bug or two, just need to find it.
If you like, I could post a copy of my NxOgre here for you to try out to see if my fluid problems are the causes of the recent changes?
Karan
21-05-2010 23:05:18
Well, the particles can't die, because their lifetime is 0 and the choice of the renderable couldn't affect that, could it? (the position and velocity renderers show up to 65k particles correctly)
I still tried the VisualDebugger, and of course it shows all partices even when Ogre doesn't^^
I don't have any shaders yet, just one simple fixed function material, but that shouldn't matter that much...I'll try out your code if you post it.
betajaen
21-05-2010 23:18:51
It must be Ogre related then, have you tried a different renderable type; i.e. Critter::Enums::FluidType_Velocity ? If they show up, perhaps there is a way to increase the Ogre particle limit.
Cheers! I have the code attached, few remarks:
- Only use the VC9 project.
- Just compile the NxOgre project the one with the CC project will fail.
- TimeController is missing, just use "mWorld->advance(...)" instead; You see when you compile your code.
betajaen
22-05-2010 22:26:07
Changes, Changes, Changes!
[attachment=1]Clipboard Image.jpg[/attachment]
TimeControllers
In a previous post, I mentioned that I removed the TimeController class and changed the timing system. Well that is true. Obviously this will break your code. So this is the quick fix:
From
mTimeController->advance(deltaTime);
To
mWorld->advance(deltaTime);
Fairly easy fix there! Anyway. In detail; the TimeListener class that you may or may not use, it now Scene based instead of World based. Additionally TimeListeners can be called before the Scene starts to Simulate, or the Scene starts to Render. No more messing around with priorities!
Anyway, this a diagram or two. I made up when designing the thing. Looks pretty and seems to work.
[attachment=4]world_advance.png[/attachment]
[attachment=3]scene_simulate.png[/attachment][attachment=2]scene_render.png[/attachment]
Garbage Collection and Containers
This is all internal stuff, that you should never use. But it's worth a read anyway.
All the containers have been rewritten and use the STL container system. We have vector, map, multimap, hashmap and multihashmap. Every function name is consistent and all use optional garbage collection.
All new/delete operators go through a new namespace "GC" these are safe_new or safe_delete, which use the existing Allocator system, and go through the nice new optional memory debugger that writes nice HTML 5 files explaining exactly where each byte is going to!
[attachment=0]Clipboard Image2.jpg[/attachment]
CCD!!!!
Finally, got CCD implemented. I had to design a special file schema for CCD, due to the weird way CCD meshes are implemented in PhysX. I still need to modify flour so it can write the meshes, but all my initial tests it seems to work.
Other secret things
I'm working on a secret project for all the newbies. A complete tutorial series explaining all of the NxOgre features. I'm on the 11th part out of
~89. The first 13 will be publicly released on the next commit which will be in a week or two.
Karan
22-05-2010 22:44:19
It must be Ogre related then, have you tried a different renderable type; i.e. Critter::Enums::FluidType_Velocity ? If they show up, perhaps there is a way to increase the Ogre particle limit.
Cheers! I have the code attached, few remarks:
- Only use the VC9 project.
- Just compile the NxOgre project the one with the CC project will fail.
- TimeController is missing, just use "mWorld->advance(...)" instead; You see when you compile your code.
Yeah, I've tried all renderable types and the problem is only with the OgreParticle one.
I tried your code and it makes no difference - framerates are roughly the same and particles still disappear. I also tried it in debug mode and it wasn't much worse (nearly 60fps at 30k particles and 14fps at 60k particles).
I'll see if the problem lies in the Ogre particle system then...
betajaen
22-05-2010 22:46:03
Sounds like Ogre is the culprit then.
[Edit]
I've asked on the main forums for you.
spacegaier
23-05-2010 17:39:02
betajaen, you rock! Nice stuff
!
KyleKatarn
02-06-2010 17:15:12
Hey, congratulations on implementing CCD. If I understand it correctly, CCD is used to detect collisions for very fast, almost instantaneous movement, such as a bullet fired out of a gun, yes? Say for example, in a first person shooter, if you fire at a brick wall with an enemy on the other side, there's a good chance the bullet is going to clip through the wall, and kill the enemy anyway with CCD turned off, but when turned on, it can detect when the bullet hits the wall and stop it there? Am I on the bat, or out of the playing field on this?
Anyway, can't wait to try it out in the next build. And the promise of tutorials intrigues me to no end.
Can't wait
betajaen
02-06-2010 18:37:02
It's more like bows and arrows in practise. CCD is pretty good but not that good in my experience.
I just need to finish the cloth tutorials (and fix any bugs I find with them), and I'm ready to commit.
Karan
04-06-2010 14:21:13
About the
Ogre particle limit problem: will you fix it, betajaen? I've done some shader stuff in the meantime because I thought you might^^ Otherwise I'll do something in the near future. If you do something I've got a suggestion: make the quad (billboard) size default to the physical particle radius (which is kernelRadiusMultiplier / restParticlesPerMeter). And also add a function to manually set it (because for rendering a surface the quads should be a bit bigger than that).
And another thing: I dont want to always fill the fluid "tank" with an emitter, but rather have it prefilled (to save time and for a dam break scene). So ideally I'd like to be able to save the positions of the particles to a file (but you removed Fluid::getParticleData() because of the shared pointer problem, right?) and then load them the next time via the
initialParticleData field of the FluidDescription - which doesn't exist in your wrapper class yet.
Could you do something about it or guide me to the easiest solution for that?
betajaen
04-06-2010 15:02:39
No, I moved over to fixing/implementing cloth.
I will get back to it though, probably in the next commit or the one after that. The new SharedPointer and Renderable code should make things better and easier now anyway.
betajaen
04-06-2010 15:21:13
Detritus/Syllabary
Complete rewrite of the container and allocator system.
Most if not all classes will be affected.
Please report any leaks or strange behaviour to the Detritus forum post.
OGRE Users should upgrade to the latest Critter when using this commit
- Removed TimeController class. Use World::advance instead
- Replaced functions of TimeController listeners to Scene.
- Added vector, map, multimap, hashmap and multihashmap containers
- Rewrote "Buffer" class to "buffer" class.
- Rewrote SharedPointer class.
- Added GC allocator namespace
- Added NxOgreConfiguration.h namespace
- Changed some code to aid with compatiblity with the GCC compiler
- Added Heightfield serialisation functions
- Added X-Binary serialisation class
- Updated NXS serialisation class
- Updated Flower serialisation class to handle skeletons
- Implemented CCD Skeletons
- Added a NX_PARAMETER interface to World
betajaen
04-06-2010 15:25:07
Do'h, I forgot to mention. The CharacterController project will fail at compiling -- I forgot to copy the new source files over/remove some old.
Will be fixed in the new commit.
betajaen
05-06-2010 14:36:57
Detritus/Haddock
- Removed NxOgreCharacterController.vcproj file
- Added NxOgreHasCharacterController configuration option
- Renamed "NxOgreDebug" and "NxOgreFinal" configurations to "Debug" and "Final"
- Changed name of Final dll name from NxOgreFinal.dll to NxOgre.dll
Note: There is a newer Critter commit that you should use with this.
betajaen
09-06-2010 20:52:05
In a few weeks time. I'm going to release a first copy of the NxOgre SDK with binaries in an installer format.
It should consist of:
- NxOgre Detritus. Headers and libraries (Debug and Final versions). Both in Character controller and Non-character controller versions.
- Critter. Headers and libraries (Debug and Final versions)
- Compiled versions 101-113 of the NxOgre tutorials, Some of the joint tutorials, 1000-1005? of the Cloth tutorials, and the single Character controller tutorial, with source code.
- Media for the tutorials.
- Flour 0.4.6. Compiled version
- Ogre MeshXML to Flour Ruby converter
- Blender exporter
According to plan, there will be two RC versions then a final. After that I'm no longer supporting BM or Bleeding anymore and recommend everyone to use/upgrade to Detritus.
QXman
11-06-2010 18:28:02
Nxogre1.60 can use the Ogre 1.65???
betajaen
11-06-2010 18:30:56
Critter was written with 1.7.0 in mind, but you can try it out in 1.6.0 and make any needed changes to make it work.
QXman
12-06-2010 12:27:18
Critter was written with 1.7.0 in mind, but you can try it out in 1.6.0 and make any needed changes to make it work.
thanks .
Another problem, I use the Ogremax 1.71 export (box01.mesh) and use Flour.exe convert box01.nxs files.
but have one error:
E:\flour>flour convert in:box01.mesh, into:triangle, out:box01.nxs
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
but ,I use the OgreMax 1.65 export Box02.mesh and use Flour.exe convert to Box02.nxs .
is OK.
I use the Ogre1.71 and NxOgre 1.63 .
betajaen
12-06-2010 13:37:40
The latest flour's do not use the Ogre Mesh anymore. Instead it uses a different file format called "flower" instead. There is a blender exporter and a Ogre MeshXML converter in the exporters directory.
http://github.com/betajaen/NxOgreSerial ... /Flower%2F
I believe Ageia has written a NXS exporter for 3DSMax which you can directly save your meshes as NXS files, NxOgre can read those directly.
betajaen
20-06-2010 18:45:09
Detritus/Traumatic
Detritus/Traumatic
Added support for CharacterController from the NxCharacter.dll*
Added FlatYAML serialisation
Added Value class
Added support for "Dirty" Actors and Shapes -- Actors/Shapes that have been created outside of NxOgre.
Added Physics Functions for Volumes
Changed Volume Callbacks to handle CharacterControllers
Changed Raycasting to handle CharacterControllers
Changed TimeListener to pass on the state of the Scene (if it is Simulating or Rendering)
* To enable/disable the character controller.
Find and adjust the following line in NxOgreConfiguration.h and recompile
#define NxOgreHasCharacterController 0
0 -- To Disable, 1 -- To Enable
Although the
CharacterController is working and implemented. I am working on a more better solution in Critter, called "AnimatedCharacter" which will be based on the CharacterController and quite similar in workings to the Ogre Character demo in the recent 1.7.0 Samples.
There will be also a tutorial in the NxOgre tutorials explaining on how to use the Character system. But if you've used NxOgre before and the PhysX character controller, it should be self explanatory.
betajaen
20-06-2010 20:45:40
Posted latest Critter, you should download that if you upgrade to Traumatic.
Brakok
22-07-2010 00:11:54
Hi, Im using the newly implemented CharacterController and just want to ask if I misunderstood the GetPosition on it. When I used it, I only get the initial position even if I move it. But, if I uses the GetGlobalPosition on the NxActor contained in it, the Controller is moving. I just want to know if it's ok and I didn't understand it or it's an issue?
In hope that it helps.
betajaen
22-07-2010 09:11:21
It's a weird bug that's been around for ages. I believe using getNxActor->getPosition is the correct way, but may be inaccurate (we are talking tiny teny float values here).
I've already updated NxOgre to use that instead of the buggy getPosition.
oggs91
18-08-2010 02:40:59
hi, today i've started with ogrenx/detrius from git and it works great =)
but i don't know where to start with the character controller =/ is there any tutorial or example out?
today i create such a nice terrain in ogrenx, would it work together with the cc ?
just give me a few lines of code, that i know where to start
Edit:
what i did so far -> create a charactercontroller through a scene, moving the charactercontroller, collision with other charactercontrollers works
how works collision with terrain, and how do i use the callback
Edit2:
got the collision with other working =) ->setCollisionEnabled(true);
Kissy
22-08-2010 23:01:11
I am trying, like lot of people here
, to make a CharacterController.
Do you have an update on the Critter CharacterController release ?
That would be great :p
Thanks a lot !
betajaen
22-08-2010 23:07:36
I've been working on another project, so I haven't had any chance to work on the CC code at all.
Kissy
23-08-2010 00:10:42
It's totally understandable
I am trying to make one, based on the CritterAnimatedController you have made.
I have however few issues.
The getPosition is wrong, so I made the trick you said :
Vec3 CharacterController::getPosition() const
{
return Vec3(mActor->getGlobalPosition());
}
But When my Capsule move (via the gravity), the getPosition Vec3 returned doesn't change.
PS : I don't have any mesh to display the actor, I am using only the controller and the visualDebugger to see that, does it matter ?
Thanks a lot
betajaen
18-11-2010 21:29:04
Okay, and I'm back.
Fast Building
Just added two build modes which are to designed to gain my sanity back. They are named "DebugFast" and "FinalFast", which borrow the
Unity building technique. I also wrote a small Ruby script to automatically generate the extra file needed for it to work, it's automatically run when compiling -- so I don't have to lift a finger.
These are the results:
Final -- 00:02:46.67
FinalFast -- 00:00:11.35
I saved 2 minutes 35 seconds there! For some reason DebugFast is twice as quicker. I assume the time difference is due to the optimization put into Release builds by the compiler. I spent most of my time in Debug mode anyway, so the extra time lost is greatly appreciated.
Logging
I've expanded out the log/exception system now. It can write to a log file (the code was always there but for some reason it never did anything), with errors/warnings or notices. It also dumps out the configuration of NxOgre for quick debugging.
betajaen
25-11-2010 11:26:17
Detritus is now done.
See BuggySwires