Bloody Mess Development Blog
betajaen
24-09-2008 23:45:30
My fellow Zombies,
It seems, I've started a Bloody Mess or if you prefer NxOgre 1.1. It is the fourth rewrite of NxOgre; but I stress (for my sanity) I will copy and paste much of the old code as possible, and retain nearly all of the class structure. After 1.0'23 is out, I want to devote most of my time towards it.
These are some of the major ideas I have for NxOgre as a whole. Obviously features of PhysX are planned to be implemented but this is a general thing that applies to everything.
1. Hide away all PhysX classes; User does not have to include or link to the PhysX SDK anymore, no more PhysX classes popping up in intellisense either. I may provide a "back-door" though.
2. Names should be optional. Scenes, Actors, Groups, and so on; Don't need a name. I'm also not talking about randomly generating ones either, no names.
3. Don't include Ogre as a dependency, work on alternative classes and functions to replace what is used in NxOgre.
4. Don't use any STL classes. Use Betajaen's.
5. RenderSystems are now static libraries. Under a very free license, user includes the library in their project and links it to NxOgre on the creation of the World object.
6. Combine PhysXDriver and World together.
7. Simplify the ResourceSystem, make it abstract enough to be used by PhysX and the user.
8. Come up with a replacement for string params; make it inline code. The Boost libraries have achieved such a feat, and I have created a similar system. Expand and integrate.
9. Comment all classes and functions.
So far, I've implemented: 1, some of 2, 3, 4, some of 5, 6, and none of 9.
For testing and proving some of my crazy ideas; an application "BloodyCake" has been made. It's just a simple dos based application, that links to NxOgre. Apart from record breaking compile times, it doesn't require linkage to PhysX (or Ogre at the moment), and as a side-effect the PhysX dll's aren't required to be in the same path as the executable anymore.
So my question is to the people that I (with much affection) refer to Zombies. What do you want in NxOgre? I'm not talking about integrating feature X from PhysX, or finally adding the character controller. But think bigger, global things. Things you want changed, or things you want added.
Love, Betajaen
Rasengan
25-09-2008 20:16:36
hello Betajean, hello all!
What do you think about "some kind of link" to PhysX and shaders, into the core of NxOgre?
i.e: crysis wind effect, plant collision effect, ... are shader effects. I don't know if is there a real advantage to build some PhysX<->shaders (NxOgre<->shaders) link, it's only an idea.
The Geforce 8xxx, 9xxx, ... take already advantage of PhysX hardware acceleration, it'seems that future Radeon GPU's support is planned.
(in fact,
it's already done with 3870...), so all computations will be GPU side (physX, shaders)
Anyway, what do you think about this "NxOgre<->shaders" link ?
betajaen
25-09-2008 20:21:28
Your talking about simulating soft bodies on hardware? PPU or a GPU? I'm pretty sure PhysX can do that already.
I do like the idea of an effects system though. Not just for particles; but effectors like wind, grass. It can use different sources (CPU or GPU), work with network access (effects are client side only - but others aren't), and Ogre can easily render them.
I'll have a think.
reptor
26-09-2008 00:32:35
I would not have any other way in NxOgre to define parameters than the "class params" way. I would leave it to the application programmer if he wants to use some more flexible way.
As an example of a more flexible way, I am using Lua to define parameters - it works great. I just have structs exposed to Lua, then I first create a struct with default values, give that struct to Lua, then I command Lua to read a script file which modifies the struct as it has been written - works great. I also validate the parameters before giving them forward so there is an additional level of protection from errors (in addition to Lua and Ogre3D/NxOgre). But I am definitely not saying that NxOgre should start to use a scripting language, this is a choice that should be left for the application programmers, that's why I say "class params" should be in NxOgre only, as that doesn't impose restrictions or introduce duplicate methods to define parameters *hardcoded*. Of course there could be optional modules which could use a scripting language or something like that, but I think they should either be optional or not exist at all.
Then I wouldn't have any custom STL replacements. I think it is not reasonable to expect that a one-man project will write not only the physics wrapper, but also low-level containers. I think you are just asking for trouble
of course, if you are just educating yourself, then by all means do it. But for the sake of the project going forwards, I don't think it is a good way to go. It's a honest and straight opinion.
I agree that you shouldn't be asking for every thing to be named. It can be an annoyance, naming something just for the sake of naming.
K.I.S.S. !!!
betajaen
26-09-2008 10:45:38
I did have Lua in NxOgre one time, it was version 0.3 or something.
What I mean about losing the string portion is replacing the familiar:
function("mass: 10, linear-damping: 0.4");
With
function(_mass = 10, linear_damping = 0.4);
That way, there is no string parsing and at most just a copying of integral values.
But I cannot introduce a scripting language, it would limit the end user to one language; it would add more complexity, more uncertainty, it would be slower and some people will be put of of with the extra license.
I've already written the STL replacements (most of it); vector is Array, and map is AssociativeArray. My Array has been proven to be faster than the vector, and AssociativeArray uses the same tree (Red/Black) as map. So speed isn't an issue. Apart from dropping STL "just because", I wanted to use my own container classes for easier integration, limiting some classes to use a non-destructible version of those classes, garbage collection, and a few other things. Once, I've finished the AssociativeArray, I'll post a copy and give a few tutorials on how to use them.
Yep, names are definitely being optional now. I even have a class in mind to store them; it's across between a Array and a AssociativeArray.
reptor
26-09-2008 16:29:57
I did have Lua in NxOgre one time, it was version 0.3 or something.
What I mean about losing the string portion is replacing the familiar:
function("mass: 10, linear-damping: 0.4");
With
function(_mass = 10, linear_damping = 0.4);
That way, there is no string parsing and at most just a copying of integral values.
But why would you have that? Is there some practical reason why parameters need to be given like that? Some benefit over the style you call "class params" in NxOgre documentation? If you do that, then it will get messy quickly if you have more params. You will have to put linebreaks and then it breaks apart, so I see just using the "class params" style is cleaner. I just don't see the benefit of having more than one style for params in NxOgre; I think that should be left for the application programmer.
But I cannot introduce a scripting language, it would limit the end user to one language; it would add more complexity, more uncertainty, it would be slower and some people will be put of of with the extra license.
I didn't ask you to introduce a scripting language to NxOgre. I agree, it shouldn't be in (core) NxOgre at all. It should be left for the application programmer to decide.
I've already written the STL replacements (most of it); vector is Array, and map is AssociativeArray. My Array has been proven to be faster than the vector, and AssociativeArray uses the same tree (Red/Black) as map. So speed isn't an issue. Apart from dropping STL "just because", I wanted to use my own container classes for easier integration, limiting some classes to use a non-destructible version of those classes, garbage collection, and a few other things. Once, I've finished the AssociativeArray, I'll post a copy and give a few tutorials on how to use them.
Yep, names are definitely being optional now. I even have a class in mind to store them; it's across between a Array and a AssociativeArray.
Well, but are your containers robust? I think I saw you mention some problems with them. And then how about cross-platform compatibility? You will have lots of work to make sure that your containers work reliably on other platforms than Windows as well. If they don't work reliably, then they are useless. I'm just thinking that it's quite a lot of work which doesn't actually take the NxOgre project's main goal (create PhysX wrapper) forward. I'm just trying to reduce your workload
You could first write the whole wrapper, and after that replace the STL if you still want. Just my opinion...
betajaen
26-09-2008 16:39:16
1. We already have two ways of specifying the parameters; "string" and "class". I'm just replacing the string version with a similar style with legal C++ syntax but with less processing.
2. I must of misunderstood.
3. My Array class has been use in NxOgre (under the name of SharedList) for a while now and has no problems. Although the AssocativeArray is still being written; the "meat" of the code is based off the
Red-Black Tree code by Julienne Walker, which I imagine has been tested and used regularly in many many projects. But the STL container classes are unsuitable for what I have in mind in NxOgre; if I used them, then it would only be wrapping them. It would make more sense to use container classes that exactly match my needs with NxOgre - and I am.
reptor
26-09-2008 16:50:49
Well, my point about the params is that I would have only one way to define params in NxOgre. Then application programmer can create more ways if he sees a need.
You could reduce the amount of code you need to write and maintain if you would not have duplicate ways to define parameters. As I think we don't really need duplicate ways to define parameters in NxOgre, then I think the duplicate way should be left out completely.
As I have already done, I have my own way to define parameters via scripting, but that is not NxOgre-specific, it's application-specific (as an example, I am not exposing every physics parameter to scripting, but only those that I think the users of my application should be able to change when creating their own content).
reptor
27-09-2008 18:04:30
Do you have an estimate of when the next beta version is released?
mcaden
27-09-2008 18:43:31
Honestly I'm much more concerned with seeing the templated CreateBody functionality than anything else I've seen upcoming. By far I think it's the most useful bit of anything I've seen slated for the upcoming releases.
My opinion is a bit biased though. Things like eliminating names doesn't hurt...but doesn't really excite me. I also use the class params because to me it's more thorough so replacing the string params doesn't affect me. Also - as at the moment I'm only using Ogre, I'm not concerned with NxOgre's dependency on Ogre. The templated CreateBody stuff though I believe I would find extremely useful in my current project.
So yeah...unconcerned with 1.1...totally concerned with revision 22
Prophet
28-09-2008 19:42:45
Not sure I'm a zombie, but here I go.
Frankly, most important is to get a decent documentation. It's already badly commented (you know this), and it won't get better by not doing it. Secondly, get all the PhysX-stuff working. As reptor said, it's a wrapper. But, do what you need to do to get it working. And I really long for the CreateBody-stuff.
Otherwise, I say the ideas are good.
And do NOT drop the string params. Just keep it.
Love you too.
Caphalor
28-09-2008 22:07:01
A agree with reptor. Don't waste time developing a new parameter system (the "class way" to define params is enough, just drop string params without a replacement, it would be just more work for you) or more stl replacements. In my opinion it is much more important to wrap all important features of PhysX and document them. I know that you don't like posts like that here but I had to write it.
betajaen
28-09-2008 22:17:24
I don't mind dropping the strings for now (in fact the current code, I'm working with does not have them).
I think the most important bit is whilst getting it on it's feet, is to shove in features and standards that I don't have to add in later.
almondega
06-10-2008 16:37:28
will the next version have CCD ?
i really need it, and i think a lot of people too
betajaen
06-10-2008 16:44:57
I literally generated the first CCD mesh using NxOgre a few seconds ago, I was about to post about it.
You won't have to wait for Bloody Mess, because it's in Bleeding.
betajaen
06-10-2008 20:50:30
And you'd be happy to hear, that loading works now. For all intent purposes NxOgre now has CCD support.
Now; I just have to clean up flour, and make things more neater in NxOgre.
almondega
07-10-2008 00:31:19
perfect!!
let us know when u update the bleeding
and a little sample about how to use ccd
cya ^^
betajaen
07-10-2008 00:48:29
Probably tomorrow or the day after. I've rewritten the ShapeParams class, and I want to clean up a lot of loose ends. I also have a idea on how to clean up those nasty helper functions.
CCD is quite simple.
NxOgre::Resources::ResourceSystem::getSingleton()->addMeshAs("file://cube.xsk", "cube-skeleton");
mScene->createBody<Body>("cube.1m.mesh", new Cube(1, "skeleton: cube-skeleton"), Vector3(0, 10, 0), "mass: 10");
Prophet
07-10-2008 08:00:32
Probably I'm just stupid, but what says that is uses CCD? Is the .xsk file extension used for this, or is this something for your skeleton?
betajaen
07-10-2008 09:10:54
The "native" skeleton format has no file header; it is pretty much a memory dump. So for identification purposes when it is loaded in, it has a file header. I chose "xsk" instead of "nxs" because they are different.
Prophet
07-10-2008 09:15:45
But then, when is CCD told to be used? CCD = Continues Collision Detection, right? Used for high-velocity objects, right?
I'm a bit confused...
betajaen
07-10-2008 09:31:24
CCD uses a simple triangle mesh (which is very roughly the shape of that shape), it scales in the direction the actor is traveling. The idea is since the triangle mesh is larger than the actor it would catch parts of the other shapes for collision that it wouldn't normally would at a high speed.
The part in the shape "skeleton: cube-skeleton", tells NxOgre to put the NxCCDSkeleton pointer in the shape_desc.ccdSkeleton, and turn everything on.
Prophet
07-10-2008 10:19:16
Right, so the cube.xsk is just a large (larger) cube than a 1m cube that is used to detect collision when travelling at high speed?
It made me a bit confused, when people say skeleton, I expect... Well, a skeleton.
I'll try this sometime.
betajaen
07-10-2008 10:21:19
Actually it's slightly smaller at rest; but it fits inside the main shape which, I suppose they got it from that.
Prophet
07-10-2008 10:27:06
Oh, you surely light my lamps!
Thanks!
But if you have a cube, can't you just create a cube, not having to load a mesh from the hard drive? How much imprecision can except when it's going slow? That is, when does it start scaling outside the original? Follow me?
betajaen
07-10-2008 10:34:48
No, because some of your actors may be a more complicated shape. I wouldn't worry to much about it; Ageia pretty much the experts on this. There is a quite a long page in the PhysX documentation chm on CCD, perhaps you should read it.
Besides the XSK file is 812 bytes long, and the mesh is shared amongst similar shapes rather than copied (or loaded each time). So it's pretty efficient.
Prophet
07-10-2008 11:31:29
I will read it.
I think you misunderstood me, but it doesn't matter. And yes, Ageia is pretty much the experts on this.
By the way, I like the new template-system a lot.
Prophet
08-10-2008 07:25:51
Hm, I have a small thought. The loader that NoodlesOnMyBack is working on; it will have problems with the new body-system. Is there a default body-class to use, which you can always fall back on? Anyway, I think it would be good if you can set a default body, just like the "old" way, so that the loader can create this default instead of NxOgre's default. Very, very sketchy (just to get my point through)MyBody* buddy = new MyBody(myParams)
NxScene->SetDefaultBody(buddy)
NxScene->CreateBody<default>(params)Now, this will probably not work, but you see my point?
betajaen
08-10-2008 08:48:39
It is a good idea, and pretty easy to implement. All, you would need is a storage of an integer for it to work.
betajaen
19-10-2008 13:38:56
Alright show time
I've been working on Bloody mess seriously now for the last few days. I haven't touched anything related to PhysX yet, infact the headers aren't even imported. What I've been working on, is the robust framework and background parts of NxOgre. So when I do develop NxOgre, it's done properly the first time.
Anything that is new'd or malloced is done via the MemoryFunctions class, it is tracked via the MemoryTracking system; much like Shoggoth. It can use the standard malloc or use the nedmalloc classes (which is default). Everything is accounted for and everything is freed. So there are no leaks, and if there are - you know about them.
For example:
WorldParams wp;
World* world = World::create(wp);
MemoryFunctions::writeAllocationsToConsole();
World::destroy(world);
The writeAllocationsToConsole function writes this:
-Internal -------------------------------------------------------
|1003190c|000032|NxOgre_Public_MemoryTracker *Unmanaged*
|003002e0|000072|NxOgre_Public_MemoryTracker_MemoryAllocations
-Allocated ------------------------------------------------------
|00300260|000008|NxOgre_Private_PhysXWorld
|003002a0|000008|NxOgre_Public_LogManager
|003002b8|000024|Betajaen_List_for_LogManager
|00300278|000004|NxOgre_Public_Log
|00300368|000008|Betajaen_List_for_LogManager_Buffer
-Stats-----------------------------------------------------------
- Total bytes used : 156
which is overhead : 104
-Current allocations : 5
-----------------------------------------------------------------
And of course, once the user's application quits.
No leaks found.
We also have a much simpler and faster ResourceSystem now. It still uses the "URI" scheme from the internet like the previous generation of NxOgre to address a resource. EVERYTHING that has to be accessed externally has to be done via the ResourceSystem, meaning that writing/reading to things other than basic files is possible and even streaming things off the web.
Compile time for this new NxOgre is much much faster than Bleeding. As it doesn't link to Ogre anymore, I don't have to bring in all the unneeded headers or classes. Everything is maximum fast now, and I aim to make it stay that way.
betajaen
19-10-2008 18:41:14
And PhysX is now bound and working with the memory allocator. Ageia/Nvidia have even provided an enum to work from to identifiy what parts of memory are being used by what. Great for debugging!
-Internal -------------------------------------------------------
|100379bc|000032|class_NxOgre_MemoryTracker *Unmanaged*
|00b28d30|000744|class_NxOgre_MemoryTracker_MemoryAllocations
-Allocated ------------------------------------------------------
|00b20260|000016|class_NxOgre_PhysXWorld
|00b202a0|000008|class_NxOgre_LogManager
|00b202b8|000024|class_Betajaen_List_for_LogManager
|00b20278|000004|class_NxOgre_Log
|00b20368|000008|mem_Betajaen_List_for_LogManager_Buffer
|00b20380|000004|class_NxOgre_PhysXMemoryAllocator
|00b20398|000056|NX_MEMORY_FoundationSDK
|00b204e8|000032|NX_MEMORY_NxMutexRep
|00b20510|032908|NX_MEMORY_RemoteDebugger
|00b285a8|000196|NX_MEMORY_NpPhysicsSDK
|00b286b0|000032|NX_MEMORY_NxMutexRep
|00b286d8|000032|NX_MEMORY_NxMutexRep
|00b28700|000032|NX_MEMORY_NxMutexRep
|00b28728|000032|NX_MEMORY_NxMutexRep
|00b28750|000032|NX_MEMORY_NxMutexRep
|00b28980|000032|NX_MEMORY_NxMutexRep
|00b289a8|000032|NX_MEMORY_NxMutexRep
|00b289d0|000008|NX_MEMORY_Generic_Array_Container
|00b289e8|000008|NX_MEMORY_PhysicsSDK
|00b202e0|000120|NX_MEMORY_LowLevel
|00b28a00|000016|NX_MEMORY_LowLevel
|00b28a18|000016|NX_MEMORY_LowLevel
|00b28a30|000016|NX_MEMORY_LowLevel
|00b28a48|000016|NX_MEMORY_LowLevel
|00b28a60|000280|NX_MEMORY_NfPhysicsSDK
|00b28c68|000032|NX_MEMORY_NxMutexRep
|00b28c90|000032|NX_MEMORY_NxMutexRep
|00b28cb8|000032|NX_MEMORY_NxMutexRep
|00b28ce0|000032|NX_MEMORY_NxMutexRep
|00b28d08|000032|NX_MEMORY_NxMutexRep
|00b203e0|000164|NX_MEMORY_NfFluidMeshCuisine
|00b29138|000020|NX_MEMORY_NxMutexRep
|00b29160|000032|NX_MEMORY_NxMutexRep
|00b29188|000032|NX_MEMORY_NxMutexRep
|00b28778|000080|NX_MEMORY_Generic_Array_Container
-Stats-----------------------------------------------------------
- Total bytes used : 35224
which is overhead : 776
-Current allocations : 35
-----------------------------------------------------------------
Prophet
19-10-2008 21:02:24
Around when will this be available to the public? I'm eager to find out if this can cure my little problem.
betajaen
19-10-2008 21:12:23
Probably 3-4 days.
Most likely it will, but it will only be a Scene, Actor, Cube combination. I stress this is completely from scratch again.
nargil
19-10-2008 22:22:06
I'm sad to hear that. ;/
1. Hide away all PhysX classes; User does not have to include or link to the PhysX SDK anymore, no more PhysX classes popping up in intellisense either. I may provide a "back-door" though.
I don't like it.
2. Names should be optional. Scenes, Actors, Groups, and so on; Don't need a name. I'm also not talking about randomly generating ones either, no names.
Ok, that's kind of good, but i guess it's a matter of few lines of code
3. Don't include Ogre as a dependency, work on alternative classes and functions to replace what is used in NxOgre.
We don't need it here... on the ogre forums.
4. Don't use any STL classes. Use Betajaen's.
Ok stl sux, but there is something wrong with your containers that my intellisense can't parse them. Dunno why. An enemy i know is an better enemy
5. RenderSystems are now static libraries. Under a very free license, user includes the library in their project and links it to NxOgre on the creation of the World object.
Don't understand it exactly. I guess it's a consequence of 3.
6. Combine PhysXDriver and World together.
Hmmm i like it more the way it is. Too many functions popping up at mWorld-> arent rly good.
7. Simplify the ResourceSystem, make it abstract enough to be used by PhysX and the user.
that sounds cool
8. Come up with a replacement for string params; make it inline code. The Boost libraries have achieved such a feat, and I have created a similar system. Expand and integrate.
that means a lot of rewriting my existing code.
9. Comment all classes and functions.
cosmetic shit xD
betajaen
20-10-2008 00:11:13
Another small update
I've decided to use hashing of strings to quickly locate something in a tree/map/associative array this was partly to with a way of accessing external resources via a "Resource identifier", i.e. the location and the method of using that location. Currently we all do:
file://myfile.txt
Which it's going to stay that way. But the old NxOgre; would process that string a few times. To get the "file" part, then the file resource system would process that string again to get myfile.txt. Not only that the cost of turning "file" into a std::string then subjecting that to a lookup in a map, is quite expensive.
So we hash the "file" part into an integer, and keep copies of the split string. Making things faster.
I made a class that splits up the string, and does a hash. I call it the UniformResourceIdentifier, a bit of a mouthful, so I added a typedef to call it a URI. It's what we all use on the interweb! The URI is passed around instead of the string (using shared pointer system to keep the memory usage down)
As I'm not using the STL library, I'm creating blocks of char's in memory, and using the strings.h file on them. Not rocket science, but it makes me grateful for the alternates that we use.
Here we go
file://nxogre.log
> Protocol = { string = 'file', hash = '2090257189' }
> Location = { string = '//nxogre.log' }
file://test.txt
> Protocol = { string = 'file', hash = '2090257189' }
> Location = { string = '//test.txt' }
http://www.example.com
> Protocol = { string = 'http', hash = '2090341317' }
> Location = { string = '//www.example.com' }
file://c:/test.txt
> Protocol = { string = 'file', hash = '2090257189' }
> Location = { string = '//c:/test.txt' }
memory:
> Protocol = { string = 'memory', hash = '226666718' }
> Location = { string = '(null)' }
m:
> Protocol = { string = 'm', hash = '177682' }
> Location = { string = '(null)' }
I love it when everything is standardised and neat.
Prophet
20-10-2008 07:39:57
You mean you are throwing away everything and starts from scratch? How long will it take until we can create bodies again? Wouldn't it be better to mostly finish this so that we can have a working one, and then rewrite it?
About the new version though, I really like a new resource system, the current one sucks. A lot.
I like the nameless things, it feels stupid to having naming every single piece.
The only thing I don't like (so far) is replacing the string params. Strings are really useful when creating stuff "from a file". However, I don't know anything about the Boost libraries, so it might be good anyway.
betajaen
20-10-2008 10:28:22
It will be from scratch, but I'm going to do a lot of coping, pasting, search and replace from the old code to the new stuff. There is no point rewriting what I've done well.
As for Bodies once the Ogre3DRenderingSystem has been done - because it's moving over to there.
As for the file part of the resource system; I can't make it do archives or any special features it wouldn't be fair. If someone wants to do a zip one - go for it. But what I can do is make it have a list of paths to look in to load something.
Names are silly unless it's important.
I haven't decided what I'm going to do with the string part of the params yet, currently it's just "class params" style.
Prophet
20-10-2008 10:43:09
As for Bodies once the Ogre3DRenderingSystem has been done - because it's moving over to there.
What I'm really asking is, around how long will it take to implement Ogre? We've been holding in with physics for quite some time, waiting for features, and now you're doing a re-write. We're running out of time a little, so the question is whether we should go with the current bleeding or continue waiting.
I don't mean to press or stress you, but we have a deadline and we need to know whether we can use NxOgre or not. (We really want to!)
betajaen
20-10-2008 10:50:07
Work with Bleeding for your projects, and don't hold on until Bloody Mess. I'll still support Bleeding. I just want to move NxOgre on to something better.
Prophet
20-10-2008 10:55:34
Ok, thanks for the clarification. Now I just have to solve the floor/multiple bodies problem...
betajaen
20-10-2008 11:15:23
I have to start some Uni work today, but once I have a spare half-hour. I will look at your problem.
betajaen
20-10-2008 23:41:22
Another update
I've finished the URI code and completed most of the resource system. It can open/close files and read/write to them.
The LogManager/Log code has also been finished; although I haven't yet decided if I'm going to go through the traditional text log or the more friendly HTML log. I've also bound PhysX into it, which makes debugging easier.
This is what happens (output to the console), when something really bad goes wrong:
n:\BloodyCake\BloodyCake\Debug>bloodycake
[NxOgre] 0:[PhysX Assertion] i < sceneArray.size()
g:\scm\release\physx_2.8.1\novodex\sdks\physics\src\NpPhysicsSDK.h:157
Assertion failed: 0, file n:\bloodymess\source\nxogrephysxerrorhandler.cpp, line 57
There are 44 leaks!
-Internal -------------------------------------------------------
|1003fad8|000032|class_NxOgre_MemoryTracker *Unmanaged*
|00c48d10|001240|class_NxOgre_MemoryTracker_MemoryAllocations
-Allocated ------------------------------------------------------
|00c40260|000024|class_NxOgre_PhysXWorld
|00c402d0|000008|class_NxOgre_LogManager
|00c402e8|000024|class_Betajaen_List_for_LogManager_Logs in n:\bloodymess\include\betajaenlist.h:85
|00c40398|000004|class_NxOgre_ResourceSystem
|00c403b0|000008|class_Betajaen_RedBlackTree_for_ResourceSystemProtocols in n:\bloodymess\source\nxogreresourcesystem.cpp:42
|00c403c8|000008|class_NxOgre_FileResourceProtocol
|00c403e0|000008|Unknown in n:\bloodymess\source\nxogrefileresourceprotocol.cpp:33
|00c40660|000024|class_NxOgre_FileResource
|00c40688|000011|type_char
|00c40648|000008|mem_Betajaen_List_Buffer_for_LogManager_Logs
|00c40630|000008|class_NxOgre_Log
|00c406a0|000004|type_uint in n:\bloodymess\include\nxogrepointers.h:146
|00c40600|000004|class_NxOgre_PhysXMemoryAllocator
|00c40618|000008|Unknown
|00c40288|000056|NX_MEMORY_FoundationSDK
|00c40ad8|000032|NX_MEMORY_NxMutexRep
|00c40b00|032908|NX_MEMORY_RemoteDebugger
|00c403f8|000196|NX_MEMORY_NpPhysicsSDK
|00c48b98|000032|NX_MEMORY_NxMutexRep
|00c48bc0|000032|NX_MEMORY_NxMutexRep
|00c48be8|000032|NX_MEMORY_NxMutexRep
|00c48c10|000032|NX_MEMORY_NxMutexRep
|00c48c38|000032|NX_MEMORY_NxMutexRep
|00c48c60|000032|NX_MEMORY_NxMutexRep
|00c48c88|000032|NX_MEMORY_NxMutexRep
|00c40ac0|000008|NX_MEMORY_Generic_Array_Container
|00c48cb0|000008|NX_MEMORY_PhysicsSDK
|00c40310|000120|NX_MEMORY_LowLevel
|00c48cc8|000016|NX_MEMORY_LowLevel
|00c48ce0|000016|NX_MEMORY_LowLevel
|00c48cf8|000016|NX_MEMORY_LowLevel
|00c49518|000016|NX_MEMORY_LowLevel
|00c406b8|000280|NX_MEMORY_NfPhysicsSDK
|00c49530|000032|NX_MEMORY_NxMutexRep
|00c49558|000032|NX_MEMORY_NxMutexRep
|00c49580|000032|NX_MEMORY_NxMutexRep
|00c495a8|000032|NX_MEMORY_NxMutexRep
|00c495d0|000032|NX_MEMORY_NxMutexRep
|00c495f8|000164|NX_MEMORY_NfFluidMeshCuisine
|00c49700|000020|NX_MEMORY_NxMutexRep
|00c49728|000032|NX_MEMORY_NxMutexRep
|00c49750|000032|NX_MEMORY_NxMutexRep
|00c49778|000080|NX_MEMORY_Generic_Array_Container
|00c49800|000135|type_char
-Stats-----------------------------------------------------------
- Total bytes used : 35942
which is overhead : 1272
-Current allocations : 44
-----------------------------------------------------------------
Not to shabby.
@Prophet
I'm very sorry but my head has been in Physics books all day, and any breaks I've spent on the Bloody Mess code. I will try and sort out your problem for you, it's just this week is very busy for me. However; I'm near certain it isn't the SharedList or WatchedPointer code. The former is used in BloodyMess and is under close scrutiny.
Prophet
21-10-2008 07:55:59
It's perfectly all right, Bloody Mess and Physics are far more important. I have other things to develop in the mean time, I'm glad you're actually thinking about it.
I would prefer the HTML log, it's quite pleasant reading (even when something goes sideways). I'm thinking, if you do HTML, text can't be that far away and then you can be able to chose?
betajaen
21-10-2008 22:12:42
Call me Betajaen the man with a 1000 fantastic ideas
I've just come up with a fantastic idea of still having the RenderSystem still being separated from NxOgre; but without that stupid NodeRenderable rubbish.
As far as NxOgre knows or cares, it just triggers a "render()" function when "simulate()" is used with it. Those classes that make it happen don't have to be in NxOgre. So what I do is; once Scene is created I give it a SceneRenderer. That SceneRender is given a call to render - which with no guide or inspiration on how to do it. Since the SceneRenderer code is in separate static libraries (embedded into the User's application), it can be extremely specific. I was going to move Body over to the Ogre3DRendersystem anyway, but with this idea Body can use SceneNodes/Entities directly without NxOgre knowing.
I'll have to think it more over (with more complicated things like Cloth or particles) but I'm pretty sure it's doable.
No more NodeRenderable yuckyness!
xadh00m
22-10-2008 08:56:51
Hi Beta!
I´m not sure if I fully understand your idea. So please excuse if I´m wrong.
As I understand you would loose a bit OOP, where every "object" can render
itself instead creating a maybe huge render() method.
BTW I thought one of NxOgre benefits would be a connection between the
PhysX representation and the renderable stuff. If NxOgre would just provide
a "one render() method" interface, I could do it myself or use one of the old
PhysX samples. They just call a render method and draw some cubes etc. depending
on the PhysX representation...
What do you think?
betajaen
22-10-2008 09:13:15
I´m not sure if I fully understand your idea. So please excuse if I´m wrong.
As I understand you would loose a bit OOP, where every "object" can render
itself instead creating a maybe huge render() method.
No, no. I've explained it all wrong.
Currently in NxOgre; we have the SceneRender, which keeps a list of "Renderables"; an abstract class to represent something visually. Theses renderables are told to update themselves once every "render()". Since the renderables can represent a node based, dynamic mesh, particle, fluid and so on. It has to be very non-specific, adding to that the RenderSystem could be anything; Ogre, DirectX, OpenGL, Text based MUDs and so on so it's really abstract thus need to static_cast everything.
In Bloody Mess however, it's different. Due to Ogre not being linked to NxOgre anymore, and offloading every RenderSystem to it's own visual studio project (compiled as a .lib), I can be more specific. "Body's" now have different meanings depending on the Rendering system used. In Ogre's case, a Body is more literally NxOgre Actor, with a SceneNode and one or many entities as member variables. Much unlike the current situation. The new SceneRenderer (which according to NxOgre must implement one function only render() and has a few helper functions to use), can build up and use it's own system of rendering. In the case of Ogre3D, a collection of known moving Bodies which is iterates once every render().
This Ogre3DRenderSystem will come with NxOgre, but in the way that RenderSystem_Direct3D9 is to Ogre. They are used together, but not necessarily well known to each other.
Also; with the rendering systems that I will write, as they are linked as static .libs, I will drop the LGPL licence and make them under the very free MIT one.
betajaen
24-10-2008 23:49:54
Back to Actors
So I've been concentrating on the design of Actors a bit more. I've come to the conclusion that it is probably easier in the long run if there was a centralised "NxActor" holder class that could be inherited by anything; such as Particle, Character, Actor and so on. This allows me to also have only one type of shape system (in Bleeding we have two; Normal and Simple).
RigidBodies have a more stronger role now. In Bleeding, it was mass that determined if it was static or not. Now we have RigidBody::RigidBodyType which is an enum, that can make the RigidBody/Actor/particle/character any of these.
enum RigidBodyType
{
RBT_Dynamic = 0, //< RigidBody is likely to move.
RBT_Kinematic = 1, //< RigidBody is likely to move, but it should not have the usual physics properties.
RBT_Geometry = 2, //< RigidBody will never move.
RBT_Trigger = 3 //< RigidBody will never move, and others can pass through it.
};
Next is how I will handle shapes. I've been looking at Havok of all places to see how it's handled. It's a little messy, but has some features that I like. At first I thought I may make Box/Sphere/Capsule into one shape, something I'm still considering. But I have decided that TriangleMesh and Terrain are now one, and they are called "Geometry" to emphasise their role. The Triangle Mesh/Heightfield is more important than the shape itself really, if anyone wanted to access that - it would be done via the mesh and not the shape. Since Convex can be used with all types of RigidBodies, it will remain the same.
The next thing was how I was going to store all these things; The RigidBody class is pretty abstract (and cannot be created as a pointer). So I approached Actors first, and came up with a storage/iterator class called Actors. Using Betajaen's List and Betajaen's RedBlackTree, along with a concept I created in another Ogre project. I think I've come up with something quite elegant.
scene->getActors()->setPositionY(_Random, 8);
That will pick out some actors at random, and set the Y position to 8 metres.
Or:
ConstActors actors = scene->getActors();
actors["spot"]->addForce(0, 30, 0);
Or:
ConstActors actors = scene->getActors();
actors->setEulerOrientation(_Last, 35, 0 , 0);
And so on. Actors is a auto pointer, list/tree, iterative thing. A master copy is stored in scene, but many copies can be made and they all point to the same source.
Anyway that's it for now. I have some small amount of free time this weekend, I'm going to try and make a simple Box shape, and start on the "Text" RenderSystem. If it works, I'll post a copy, and see what everyone thinks.
betajaen
25-10-2008 23:27:36
Actors on a stage
Well, I spent this morning working on the mess, and finished the framework for shapes.
Once complete they will be:
- Box (a Box/Cube)
- Sphere (a Sphere)
- Capsule (a Capsule)
- Convex (a Point cloud)
- Wheel (a raycast wheel)
- Polygon (a point cloud with 3 or 4 vertices only - used for particles)
- Geometry (Heightfield or Triangle Mesh).
Geometry is an interesting one, it goes with the new "SceneGeometry" class that replaces the static actor concept. SceneGeometries make up the bulk of a scene. Walls, floors, mountains and so on. Since they are different from fast moving actors, particles or other bits, they can be optimised for being still.
One feature which I've wanted since NxOgre 0.4 is called Stages, these work with StaticGeometries and other things in the Scene to raise the interest in certain parts of the Scene, and lower or even turn off other parts. Stages also have added side effects, they can change "temporarily" properties of things in a Scene. Such as local gravity, materials, visibility (render system stuff) and so on.
I suppose a good example of a stage; is rooms and corridors. Once the player enters the room, and closes the door. The corridor can be completely switched off; actors frozen, the render system removes the scene nodes and so on, another good example is like in the recent game DeadSpace. To simulate different parts of a ship no atmosphere/gravity and those that do.
As you can see we are living in exciting times!
betajaen
08-11-2008 22:00:22
PhysX is a bit of a pig when it comes to memory
Busy Busy Busy. I've found time to improve on Bloody Mess, and here is what I've done so far.
First of all; The version 1.1 doesn't cut it anymore, there are so many changes and differences from it's older sister. It's now NxOgre 1.5, the big one which I've been planning for a year.
I've dropped Params, and replaced them with Descriptions. They are nearly identical to Params in usage but more flexible. They don't support "string params" anymore, they are literally three functions (constructor, reset and valid) and a load of member variables. Descriptions are inherited by Prototypes which carry a bit more information.
For example; A RigidBodyDescription, carries everything a NxActorDesc and a NxBodyDesc would of. But a RigidBodyPrototype which inherits RigidBodyDescription also carries an array of Shapes and a global pose. I hope you can see where I'm getting at; as I'm hinting at serialisation and batching.
For those who enjoy the "String Params", which I still do. I'm replacing that with a class that will deal with them all; a string to prototype class if you will. This class which hasn't been named yet can be overridden by the user. So if you hate my syntax; you can use your own, or even better use a scripting language.
Next up memory and speed. Since everything that requires memory is fed through a centralized class, we can monitor NxOgre and PhysX memory usage. Here is a partial memory dump of the memory allocated by NxOgre.
-Unmanaged--------------------------------------------------------
|100529c8|000016|_MemoryDebugger
-Currently allocated by nedmalloc---------------------------------
|00c4a0e0|006040|_MemoryAllocation (Internal Buffer)
|00c11268|000008|_ErrorStream
|00c11280|000016|_SharedArray
|00c11298|000002|_Ref_unsigned_short
|00c11308|000024|_World
|00c11330|000016|_SharedArray
|00c11348|000002|_Ref_unsigned_short
|00c11360|000008|_PhysXOutputStream
|00c11378|000004|_PhysXUserAllocator
|00c19ca8|000024|_Scene
|00c112d8|000016|_SharedArray
|00c112f0|000002|_Ref_unsigned_short
|00c35890|000036|_Box
|00c359e0|000016|_SharedArray
|00c359f8|000002|_Ref_unsigned_short
|00c35a28|000024|_Actor
|00c35a50|000004|_unsigned_short in n:\bloodymess\compiler\windows\source\nxogrebox.cpp:148
-Stats------------------------------------------------------------
- NxOgre bytes used : 6260
Overhead : 6056
Actual : 204
- NxOgre allocations : 16
- Other allocations : 145
- Other bytes used : 231412
------------------------------------------------------------------
204 bytes for this. Not to bad.
World* world = World::createWorld();
Scene* scene = world->createScene();
scene->createActor(new Box(1));
Memory::dumpNxOgre();
World::destroyWorld();
Since Bloody Mess is getting slowly towards a stage where I can show things onto a screen, I'm going to borrow one of the PhysX examples source code and modify it to work with Bloody Mess. I'll post pictures if It works.
Enjoy!
mcaden
09-11-2008 14:05:47
Lots of updates to bloddy mess, very few to 1.0'22T6.
Should we expect 1.5 to come out before 1.0.23?
But seriously, it's sounding great, keep it up!
betajaen
09-11-2008 14:28:49
Yes. I've stopped all work on '23. This NxOgre is so much better.
mcaden
09-11-2008 14:56:48
not to be a nag, but ETA?
betajaen
09-11-2008 15:03:00
I'm aiming for the first release to be usable (just scenes, actors, primitive shapes - possibly the meshes) so 15-20 days perhaps.
A lot of this stuff is much different from NxOgre; so I have to think in a different way. For example; time stepping is different now. It has priorities and I've dropped the idea of simulate/render function now. It's just "advance".
Bear with me.
But I do want to release an working example (with source) soon; today/tommorow - just a cube on a plane in an OpenGL application.
mcaden
09-11-2008 16:02:25
(just scenes, actors, primitive shapes - possibly the meshes)
So what things major would this be lacking...
CCD and custom bodies?
betajaen
09-11-2008 16:37:40
Custom bodies are done. The OpenGL version anyway.
CCD is out. It is a first/second release of code that has been written from nothing, and done in about 14 days. Give it time.
Prophet
09-11-2008 17:42:30
Not to be a hag, but the release in 15-20 days, will it be somewhat compatible with Ogre?
betajaen
09-11-2008 17:44:14
Should be. The Ogre part is just moving nodes around and creating them.
mcaden
10-11-2008 10:58:03
I'd just hoped you could expand a bit on what will/won't be there so I can see if I should implement 1.5 right off the bat. I just found a problem with an assert from mWorld->destroyScene in debug mode in T2 (not in Release)...I'm not sure whether T5 fixes it or if I've done something wrong...but I don't want to change all my callbacks to T5's system if I'm just gonna upgrade to 1.5 in a couple weeks.
I'm basically using Sphere, Cube, Triangle Shapes...addForce and setVelocity, custom bodies, and collision callbacks
All that covered? If so I'm excited.
(RE: Assert - previously I was simply deleting world, but now I've implemented my GameManager class for changing gameStates I need to be able to destroy the scene at the end of a state instead of simply doing delete mWorld since I can't delete/reinstate world. I'm not sure if I've screwed something up or if it's a bug in T2...I'm assuming it probably won't be there in 1.5 so I'm not really bringing it up as an issue.)
betajaen
10-11-2008 11:25:43
Let's see:
- Cubes are boxes and seem to be working.
- Spheres shouldn't be a problem. Almost the same as Boxes.
- Triangle Shapes a little harder; have to implement the resource system, mesh manager and SceneGeometries. Some of it will be copying and pasting some won't.
- addForce/setVelocity would be just cut and pastes from the old NxOgre.
- Callbacks, probably not on the first release.
- Custom Bodies, working on it now.
mRenderSystem->createBody(new Box(1), GLUT_Box, Size3(1,1,1), Colour(1,1,0));
5 out of 6 isn't to bad on a first release.
---
You should be able to recreate World over and over again. It's designed now, that you can pre-create some classes before world (ErrorStream and TimeController) and delete them after World has been deleted.
Apparently you can have multiple NxPhysicsSDKs thus multiple Worlds, but it would be quite difficult to implement some features.
mcaden
10-11-2008 15:06:47
I plan on releasing a prototype/demo of my game within the next 2 weeks. I think I'll leave in T2 until after the demo. Hopefully by the time I get around to it the callbacks will be in (I need to know contact between my player and enemies or my game isn't much of a game) and hopefully triangle meshes as well (my 1st level/demo will be 100% in a cavern, need trianglemesh for the floors and the walls).
I'm really looking forward to 1.5 though.
I only would possibly need to recreate World since I'm using a state system so that I can load levels and go back and forth to the main menu. What I've done instead is create world within my GameManager, and any GameState that needs a scene creates/destroys the one connected to it. I delete World in the GameManager's constructor rather than each individual GameState. I did notice a problem shutting down and deleting world dealing with the FrameListener tied into NxOgre. delete mWorld would always crash until I stopped using NxOgre's frameListener and started using my own instead along with mWorld->getPhysXDriver()->simulate( evt.timeSinceLastFrame ); and render. I've been so busy programming so many other systems I forgot to clean up my pointers and I started tracking down my memory leaks when I put in my GameManager system and found it. I don't know if it's pertinent to 1.5 but I thought I'd give you a heads-up.
Caphalor
10-11-2008 18:10:26
Take your time and develope the best
final NxOgre ever.
I think that bleeding is in a very usable state, also supporting advanced things like joints (I implemented them in my Editor which will hopefully be released soon). The only problem with bleeding is the missing character system, but I accepted it and will probably try the code NoodlesOnMyBack posted. Just implement a character system in bloody mess please.
The other bloody mess features also sound very good.
spacegaier
10-11-2008 18:17:46
I can only second the things mentioned by the other poster before: Sounds really great and yeah, we really need a character system in there this time!
And please: Go ahead for one really finished/final version. We really need one standard release of NxOgre and not that many as NxOgre 0.9, NxOgre 1.0, NxOgre 1.1, NxOgre1.5...Just totally finish one before thinking about what could be done in the next major version. Would make the whole work and participation on this project a lot easier.
I really appreciate all the work and effort you put into this project!!!
betajaen
10-11-2008 18:18:58
I agree, I really dropped the ball in not implementing the Character Controller.
But I'm really happy and proud with Bloody Mess. It reminds me the time when I first started programming "0.9", everything was so new, different and awesome.
betajaen
12-11-2008 00:00:27
This isn't much but:
Spinning box in zero-g.
I just finished of the time-controller class, and the matrix conversion code seems to be working. I've also implemented nearly every function of NxActor as inline functions that various RigidBody derartives can use, without messing with the NxActor or using PhysX directly. That is also a GLUTBody, a derrivate of Actor gaining all of it's functions. It's implemented in GLUTBody.cpp/.h
class GLUTExportClass GLUTBody : public NxOgre::PointerClass<_GLUTBody>, public NxOgre::Actor
{
friend class GLUTRenderSystem;
friend class ::NxOgre::Functions::ArrayFunctions<GLUTBody*>::Write;
public:
/** \brief Required since Actor is also a "PointerClass".
*/
using ::NxOgre::PointerClass<_GLUTBody>::operator new;
/** \brief Required since Actor is also a "PointerClass".
*/
using ::NxOgre::PointerClass<_GLUTBody>::operator delete;
/** \brief Draw the actor on the screen.
*/
void render(void);
protected:
/** \internal. Use GLUTRenderSystem::createBody
*/
GLUTBody(GLUTBodyPrototype*, NxOgre::Scene*);
/** \internal. Use GLUTRenderSystem::destroyBody
*/
~GLUTBody(void);
protected:
unsigned int mVisualShape;
float mWidth;
float mHeight;
float mDepth;
float mColourRed;
float mColourGreen;
float mColourBlue;
bool mShadows;
};
GLUTBody::GLUTBody(GLUTBodyPrototype* prototype, NxOgre::Scene* scene)
: Actor(scene)
{
create(prototype, scene);
mVisualShape = prototype->mVisualShape;
mWidth = prototype->mWidth;
mHeight = prototype->mHeight;
mDepth = prototype->mDepth;
mColourRed = prototype->mColourRed;
mColourGreen = prototype->mColourGreen;
mColourBlue = prototype->mColourBlue;
mShadows = prototype->mShadows;
}
GLUTBody::~GLUTBody()
{
destroy();
}
void GLUTBody::render(void)
{
// Render actor
glPushMatrix();
float glMat[16];
getGlobalPose().toReal16_ColumnMajor(glMat);
glMultMatrixf(glMat);
glColor4f(mColourRed, mColourGreen, mColourBlue, 1.0f);
glutSolidCube(1);
glPopMatrix();
// Render shadow
glPushMatrix();
const static float shadowMat[]={ 1,0,0,0, 0,0,0,0, 0,0,1,0, 0,0,0,1 };
glMultMatrixf(shadowMat);
glMultMatrixf(glMat);
glDisable(GL_LIGHTING);
glColor4f(0.1f, 0.2f, 0.3f, 1.0f);
glutSolidCube(1);
glEnable(GL_LIGHTING);
glPopMatrix();
}
If it's that easy to implement a GL/GLUT version of a Body; wait to see how small an Ogre one is.
betajaen
12-11-2008 00:27:57
Okay. I've decided to be nice and post a really early copy of the executable and compiled DLL. Just to see if it works in different environments and to prove I'm not making things up.
I expect it may work. They are the debug versions of the executable/dll so, Windows may have a fit. Then there are the manifests and other Microsoft essentials. So if it doesn't run, no biggie.
http://www.nxogre.org/screens/BloodyCake-Demo.zip
Just unzip and double click on the executable. You should see sixteen cubes spinning around. Thats it. Close to finish.
BTW: You may be surprised on how fast it starts up. I'm telling you Bloody Mess is FAST.
penguin
12-11-2008 01:36:29
mcaden
12-11-2008 05:17:12
It worked for me. Shadows are messed up a bit but that's not important.
XP + .NET 2.0
Illidanz
12-11-2008 08:19:50
http://www.nxogre.org/screens/BloodyCake-Demo.zip
.NET Framework error. Side-by-side Configuration is wrong.
I have Vista, .net Framework 3.5
Same error here
XP + .net 3.5
spacegaier
12-11-2008 09:30:26
Not working on the university computer, probably due to uncorrect application configurations (at least this is what ther error message says). I'll try it this evening at home.
betajaen
12-11-2008 10:38:15
No biggie. To be honest, I was expecting an error like that. You could try installing flour. It has the same manifests/dlls as my computer does, and it may work.
Prophet
12-11-2008 14:48:49
Works here. Yeah, it was really fast.
Just a qualified guess, but I think the shadow problem is because the cubes goes through the ground, but not the shadow (obviously). But I reckon a clever man/woman like you had that all figured out.
mcaden
12-11-2008 15:18:29
Yup, that's what's going on.
Like I said, not important.
We're in this forum for physics, not shadows.
betajaen
12-11-2008 16:03:05
Okay. I've finished off the functions for Actor and RigidBodyFunctions. All neatly done and commented. As each type of RigidBody is different; some functions are implemented based on their type. i.e. SceneGeometries don't need the force functions, and Actors don't need the kinematic ones. It'll catch some people out first; but that's how it should be.
I've expanded the TimeController a little. It's in the demo, but now it's a bit better. TimeControllers use a priority system; basically an array of arrays of TimeListeners in order of what should be executed first. Scenes actually have two. One is the highest, and tells PhysX to start processing the next time step, then later on in MediumHigh it collects it. Then in the case of the demo later on the RenderSystem uses those results and renders them to the screen. You can also move Scene down in "rank", and render the results from the previous frame first. It's all quite clever, and makes you wish we had this all this from the beginning. Anything can be a TimeListener; which makes it more fun.
I should start working on the other shapes now. Boxes are getting boring.
spacegaier
12-11-2008 16:57:20
I've installed now the PhysX System Softare version 8 as well as Flour 0.32 (the latest, right?). When trying to launch the demo, I get the following error:
- The procedure entry point "cuCtxDestroy" was not found in the DLL "nvcuda.dll".[/list:u]
nargil
12-11-2008 17:15:02
betajaen
13-11-2008 19:06:17
Okay. Last night; I did Sphere and Capsules, and uring my lunch hour today, I implemented the PlaneGeometry (shape) and ShapeGeometry classes. I also re-discovered how awful the default material settings are in PhysX. Everything keeps sliding around. So I'm in the mid-process of writing the material class again. Since when was their a NxMaterial class? I'm sure it was just functions in NxScene.
Oh well.
mcaden
14-11-2008 03:17:02
I had the same problem until I changed gravity from -9.8 to -98.
That's one thing I haven't understood about NxOgre. Every site I've seen said that gravity in PhysX should be -98, but on these forums every post says -9.8.
When I had it at -9.8 everything slid around like it was ice-skating. When I put it at -98 things slid around like...well...like pushing a cardboard box across a linoleum floor; how far it slides depends on how heavy it is and how hard you push it.
Rasengan
14-11-2008 03:20:11
The demo works.
XP64 .net 2.0
Prophet
14-11-2008 09:36:19
Strange. I set my gravity to -9.82 and uses the default settings and it's almost too much friction. (But that's only for shapes vs. floor, not shape vs. shape)
mcaden
14-11-2008 12:19:05
Cube shape against a TriangleMesh skates around like ice unless I turn LinearDamping up to like 10...
but with LinearDamping at 10 if I jump or fall off something I fall like a feather.
If I set gravity to -98 and LinearDamping to 0 I fall rather realistically and move with decent friction. It's odd I'm not getting the same results as Prophet (unless he's got LinearDamping up a bit).
betajaen
14-11-2008 15:53:04
Okay; I've been playing around with the TimeController a bit more, and the GLRenderSystem. It is now possible to render one ahead of the Physics by just messing around with the priorities.
For example:
(Process then render) : Calculate, Fetch Results, then Render
Scene::mProcessingPriority = High;
Scene::mFetchingPriority = MediumHigh;
GLRenderSystem::mRenderingPriority = Medium
(Render then process) : Calculate, Render, Fetch Results
Scene::mProcessingPriority = High;
GLRenderSystem::mRenderingPriority = MediumHigh;
Scene::mFetchingPriority = Medium;
I've also put in an experimental system of; in event PhysX not finished yet processing the scene; it won't enter a loop and continue waiting (as is the case with NxOgre currently). It will remember and come back slightly later in a lesser priority, and even in the next time step, before the High Priority ones.
And the material class has been added. Probably time to start on meshes and porting the resource system over.
betajaen
15-11-2008 23:04:45
Just finished nearly all of the SceneDescription/ScenePrototype bits. I even found a "jittering" problem already. Seems the fixed timestep is very sensitive. I wrote down 1.0/60 wrong as a constant, and threw the entire scene off. Something for Luis to look at one day, I think.
I've decided on a rough order for development now. The timeline range is about two months or less.
1. Copy over the resourcesystem classes that I wrote.
2. Copy over the logmanager and log classes that I wrote.
3. Create SharedMemory and SharedPointer classes.
4. Create MeshManager class
5. Create ManualMesh class using SharedMemory and SharedPointer classes.
6. Implement Convex and TriangleGeometry shapes.
7. Create HeightfieldManager class
8. Create ManualHeightfield class using SharedMemory and SharedPointer classes.
9. Implement TerrainGeometry shape.
10. Create KinematicActor class.
11. Create OgreRenderSystem
12. Create CharacterController.
I think that should cover all of the basics and much of what people want from NxOgre.
spacegaier
15-11-2008 23:20:54
Sounds great having all these points in NxOgre within the next two months, especially the Character stuff!!!
betajaen
15-11-2008 23:36:07
Apart from the Character Controller, we have all of this in NxOgre right now.
It's annoying to re implement it all, but a direct copy and paste wouldn't work. I'm just hoping it will be a stable platform by then, that I can force everyone to use 1.5 unless they want something special.
spacegaier
15-11-2008 23:39:36
I know that we have almost all these things in the old NxOgre, but I want the new one, that will be the standard/stable one that everyone will use(and hopefully love).
betajaen
15-11-2008 23:52:00
Well you can scratch most of point 3 of the list. Just did SharedPointer.
spacegaier
15-11-2008 23:54:53
Damn, you are fast. Point 1 and 2 also already done?
Prophet
15-11-2008 23:59:12
Wow... It took like half a year, at least, to get this point with the old NxOgre. I know, you've been working with it behind the scenes, but still. Must really be something extra.
betajaen
16-11-2008 00:19:45
There are actually TWO Bloody messes. The first one; was my first attempt. It's actually slightly ahead than with the second one I'm working with now. I had a serious problem with shapes being allocated in the users space, and NxOgre having problems accessing the functions of that pointer. Something would get corrupted. Turns out; I was exporting some of the functions. Which confused things.
I didn't know this at the time, and blamed it on the array code. So I started again, and after 2-3 weeks. I had the same problem. I knew you could allocate pointers in the user application and use them in the DLL. Bleeding, Ogre and every library I've come across did it all the time. So I started dumbing things down. Checking to see if there was a problem with the class, so I created it internally. Which worked. I found the problem eventually. I was hiding the functions; because I was passing on PhysX classes as arguments. When Cake got a hold of those headers, it wouldn't know what they are and fail.
So I cheated, and copied and pasted all of the PhysX classes that I know of, into a separate file that Cake can view. It's called NxOgrePhysXPrototypes.h with no definitions, it seems happy. Even GLUTRenderSystem (which doesn't link to PhysX), doesn't know what NxActor actually is. But is happy to pass the pointer around.
So in a sense; I've written Bloody Mess. Twice. In 5 weeks.
nargil
16-11-2008 01:54:56
1. Copy over the resourcesystem classes that I wrote.
2. Copy over the logmanager and log classes that I wrote.
3. Create SharedMemory and SharedPointer classes.
4. Create MeshManager class
5. Create ManualMesh class using SharedMemory and SharedPointer classes.
6. Implement Convex and TriangleGeometry shapes.
7. Create HeightfieldManager class
8. Create ManualHeightfield class using SharedMemory and SharedPointer classes.
9. Implement TerrainGeometry shape.
10. Create KinematicActor class.
11. Create OgreRenderSystem
12. Create CharacterController.
I think that should cover all of the basics and much of what people want from NxOgre.
+13. Triggers & callbacks plz
Oh and 1 more thing... 2 months is way too long. You have time till end of december! ;>
[j/k take all the time you need]
betajaen
16-11-2008 23:13:15
I'm going to add another point, as a pet project.
1a. "http" resource system. Able to stream files of the web directly into NxOgre using libCurl.
nargil
16-11-2008 23:26:30
What is it good for ? I mean if someone wants to make a mmorpg with stages made on a server, then he has to handle libCurl himself to download sounds, visual meshes and other. Adding this feature is useless, because downloading nxs / xhf / whatever_physX_related in a different way than the rest would only make the code less readable, and require additional coding. After download its better when they are stored, so... additional coding. Downloading it over and over again would kill the bandwidth.
betajaen
17-11-2008 00:16:36
It's just a pet project I have in mind. Doesn't have to be serious, and I didn't mention about adding a local cache.
spacegaier
17-11-2008 16:47:34
I also do not see the great benefits and the need of having such a streaming feature in NxOgre. I would leave it out (it just produces more code).
And if you will implement it nevertheless, then please postphone it to the end ot your dodo list. The other features are far more important!!!
Just my two cents...
betajaen
17-11-2008 16:55:32
It's practice for when I do alternative resource systems. You do want it to read from zip files don't you?
betajaen
17-11-2008 21:49:10
Okay the ground work for the resource system has been placed. It uses buzz words like "UniformResourceIdentifier" and "ResourceDirectionality_Omidirectional". It can work with normal files, and theoretically work with streaming.
I've implemented an Archive class that represents a group of resources. It could be a folder (or folders), zip file, webpage, or a rock. Those are created by ArchiveFactories which are registered into the ResourceSystem class.
An archive is recognized by the URI:
zip://media1.zip/rock.nxs
However; I'm not fond of the name "ArchiveFactory" it's too much like Java. I don't like ResourceManager either.
Any ideas chaps?
nargil
17-11-2008 22:33:25
ResourceGuy
ArchiveBakery
example code of CAKE
ResourceGuy_Goes_to_ArchiveBakery_And_Bakes_a_Cake()
betajaen
17-11-2008 23:36:22
ResourceLibrary?
[Edit]
What about ResourcePool?
nargil
18-11-2008 01:05:16
What about ResourcePool?
Only if a zergling is attached to it.
Make it epic: ResourceChest
mcaden
18-11-2008 05:23:17
Pantry!
Ensced
18-11-2008 11:21:41
I have a question, sorry if I am stupid but Can we use Flour with the new NxOgre 1.5? Or we must waiting a new flour's version?
mcaden
18-11-2008 11:50:15
I'd say that's not a stupid question at all
nargil
18-11-2008 12:02:46
This should be compatible. I mean it would be a pain in the ass if someone had to bake all the meshes again. Rewriting the NxOgre code in our engines is enough (or even already too much)
betajaen
18-11-2008 12:05:57
The file structure of the NXS files is up to Ageia/PhysX. I just do the writin' and readin'. So you should be okay. The NxOgre specific file-formats; xhf and xsk will most likely stay the same.
How about ResourceProtocol guys? I quite like that one.
nargil
18-11-2008 14:15:29
Just leave it manager ;/
betajaen
18-11-2008 15:09:53
No, I don't like ResourceManager. It doesn't mean anything. ResourceProtocol is better because it deals with specific protocols; file and zip for example.
nargil
18-11-2008 15:35:41
ResourceProtocol sounds like
enum ResourceProtocol
{
ZIP_PROTOCOL,
HTTP_PROTOCOL,
FILE_PROTOCOL
};
Not like something that "MANAGES" resources. Make it Pool if you have to, but plz not Protocol. It confuses too much.
betajaen
18-11-2008 15:45:20
Well it manages as well; it creates and closes archives and creates and closes resources. It also keeps a master copy of those pointers as well.
Prophet
19-11-2008 20:04:06
So a hybrid between Manager and Protocol?
ResourceProtocolManager? (Yes, that's a mouthful, but we do have intellisense, but it's perhaps not so clear)
betajaen
19-11-2008 20:42:12
I've gone with ResourceProtocol.
I'll explain briefly how the new system works, it's quite clever, and follows Ogre's (ever so slightly).
Resources are loaded through a Protocol; protocol being the code that loads the thing in and deals with any additional filesystem/compression/network stuff it has to go through. It's completely transparent to the user and nearly all of Bloody Mess. Example protocols are; win32 file system and zip files.
Archives contain resources. Archives are treated the same to NxOgre, but the protocol it's more specific. In a protocol sense; an archive could be a directory or a zip file. But to NxOgre they are all lumped together.
You create/register an archive like so:
ResourceSystem::getSingleton()->openArchive("media", "file://c:/Program Files/myGame/media/");
ResourceSystem::getSingleton()->openArchive("goodies", "zip://c:/Program Files/myGame/goodies.zip");
It then goes through the archives, and looks at things inside.
Then to access a resource, you just need to know what archive it is in.
ResourcePtr resource = ResourceSystem::getSingleton()->open("goodies:cake.nxs");
ResourcePtr resource = ResourceSystem::getSingleton()->open("media:island.xhf");
Not to shabby.
betajaen
20-11-2008 23:48:27
I got a little bored with the ResourceSystem. Nearly all of it is writing the same functions over and over again, just with a slightly different type. So I've decided to take a break for a bit.
Kinematic Actors
Took me 20 minutes to implement this:
mScene->createKinematicActor(new Box(8, 1, 8), Matrix44(Real3(0, 7, 0)));
With the RigidBody class, everything is routed through a single set of functions and classes which makes all of these things much much easier to implement. Since it was so easy to do; I MAY start writing the Character class tomorrow.
Then I want to start on a soft-particle system idea I've had for almost two years. But I'll need the resource system for that AND Ogre.
betajaen
21-11-2008 15:56:39
A LOT of people will be happy to hear. I've started writing the Character system classes. But don't get off your seat just yet, it's based off the code provided by Ageia.
It will use the KinematicActor class for it's base; with lots of functions and capabilities that you don't get with a standard Actor with a kinematic flag. Such as collision responses, callbacks, and so on.
But I will have to port-over and rewrite much of the sweeping functions and logic that Ageia wrote. So it will take some time.
Now, you can get off your seat and dance.
xadh00m
21-11-2008 19:20:56
Glad to here it! Thanks for your work! Is it the common way to use a kinematic actor?
I found this article some weeks ago and this approach seems to be more native:
http://www.ogre3d.org/wiki/index.php/Og ... _Character
betajaen
21-11-2008 19:31:38
I don't know if it's the common way. But it seems to be the most accurate and controllable. But I'm sure in Havok they use something similar.
betajaen
23-11-2008 22:38:21
Okay. Still working on the KinematicController classes and almost knee deep in PhysX source code.
With respect to Ageia; but some of the stuff in there can be seriously improved upon. One example to our viewers here; is the allocating memory of the total controllers twice for every move. The trick is to use a shared memory space between the controllers and only re-allocate if the controller count has changed. You use much less memory and more speed.
I'm only 30% through this at the moment, and I keep getting lost when writing functions. But from what I've read so far - Ageia have written some really good code here. It's just a little messy
xadh00m
23-11-2008 23:21:32
I´m glad to hear, you got back to the character code. We are currently
working with 0.9 and there are some issues with this release and with PhysX 2.7.3
we would really like to leave behind...
mcaden
25-11-2008 11:48:27
quick question about the character code that is to come...
From what I understand the code with it is pretty robust. What's the overhead on it like? Will a couple hundred enemies inheriting as characters bog it down? (appropriately put to sleep when far away from the player of course)
And how exactly is character customized? Is it similar to the custom bodies?
Once the characters, custom bodies, TriangleMesh, velocity, collision and getOrientation/Position stuff is in fully with Ogre I'll definitely be migrating over.
On a sidenote: You mentioned you're using sweep. Can you give an example of Sweep? I've been searching and searching and haven't found a single tutorial or code example dealing with it. Would it be suitable for and AI's sight range for spotting enemies and obstacle avoidance?
betajaen
25-11-2008 12:02:54
I've worked with people using it, and it really goes down hill when you use a lot of them. I think I know why now.
The Character controller code implements it's own sweeping code and doesn't use the PhysX linearSweep functions at all. It might be because of when the Character controller was created, PhysX didn't have those functions, so they wrote their own or it's just faster than the linearSweep functions.
The overhead is quite big; from what I understand. It uses several arrays. One being twice the size of the number of controllers, and each "move" per controller. It gets them and processes them for collision. It also gets a chunk of shapes from using intersections to narrow it down. From there it then just uses simple math to check for collisions. This isn't per frame. This is per move per character per frame. So there is a lot of memory allocation and freeing going on.
I've decided to use the PhysX linearSweep functions which has taken a fair chunk of work out, and theoretically use less memory because of the caching function it has. I'm already on the "side pass" code and I started on the rewrite yesterday.
I'm a long way of actually getting this working, and there are tons of features; such as callbacks, collisions with Actors and other CCTs and other tiny things to implement. But I'm actually starting to understand how this all works.
Don't get me all wrong though. The CCT code is really cleverly written. The auto-stepping code is way more simpler than I imagined.
----
Sweeping is like projecting a box or a capsule in a direction. It's like 3D ray-casting. You get a list of all of the hits; world positions, normals and that lovely stuff to work with.
Personally, I would try using ray-casting and intersections for AI stuff. I think it's faster. Sweeping is for more predicting movement.
betajaen
25-11-2008 14:35:29
Huzzah!
I have the controller moving around in the Scene and it's even detecting collisions.
I still have to find out why the auto-stepping isn't working (or if it is; why it won't move over small things), and implement a callback system to for responses to collisions. Currently it passes through static geometries and pushes actors out of the way (but that's the kinematic actor appearing inside it - not a real collision), and of course - optimisation. The code is a little messy at the moment.
I imagine it will be a short while before it can actually be used properly, but I should be able will release the source and a demo this week.
betajaen
25-11-2008 18:00:25
I've written the Ogre rendersystem....
nargil
25-11-2008 21:48:23
Will it be able to use a "lift" based on a kinematic box ?
betajaen
25-11-2008 22:08:29
Lift as in a British word for elevator? Or lifting as in the term picking something up?
1. Not sure on the first; could be. It does collide with the ground, but the ground won't collide with the controller. More experiments are needed.
2. Second not really related; But I have seen character controllers used to imitate a hand. You could always swap move the scenenode of the thing about to be carried into the hand node. Then put it back on the actor once done.
nargil
25-11-2008 22:38:19
Yeah elevator. Like in World of Warcraft somewhere in the taurens dessert (duuno where, dont play it - i've seen my friend playin'). He stands on a plane and is being transported up the cliff.
I ask because u said u use a kinematic actor for the character. An elevator has to be also a kinematic actor, and from what I know: kinematic actor doesn't collide with a kinematic actor, doesn't it ?
betajaen
25-11-2008 22:39:56
Nope. You'd have to sync the lift and character together. Most likely; by adding the movement direction of the lift to the character's.
nargil
25-11-2008 22:45:59
But I'll get a callback that "Character-actor" is colliding "Elevator1-actor" , right ?
Another thing: Will it respond to the ground material - for example: slip on ice ?
betajaen
25-11-2008 22:50:37
Yep. I would use a trigger or an intersection though. Just to make sure.
Actually; I think it may work on ground now. I accidentally created the character underneath the ground plane, and it was reporting collisions in all three dimensions. So you may be able to walk upon it.
mcaden
26-11-2008 08:04:29
Exciting!
I look forward to it being usable for my project.
Prophet
27-11-2008 23:03:38
I'm curious are you documenting this? I mean, if you're going to rewrite the whole thing, it would be quite an opportunity to add some decent documentation and explanations how the stuff works. It'll save you time in the long run, and you know it.
betajaen
28-11-2008 10:08:32
I've been adding javadoc comments to most functions I've written. But actually writing documentation in word - no.
nargil
01-12-2008 22:26:13
Don't want to rush you, but I'm curious whats the progress on 1.5 ? Does Ogrelicious mean that you've finished the ogre-renderer and NxOgre::Character, and now you write Cake ?
betajaen
01-12-2008 22:46:15
Stop Stalking me.
Yep, Ogrelicious will be powering BloodyCake. But I want to add a config class to it first, then do OISilicious (which will be a few classes) so I can move the camera around and debug NxOgre better.
The Ogre render is done I haven't tested it yet but it should work. It's just moving nodes, how hard can it be?
Prophet
02-12-2008 10:40:04
Famous last words.
xadh00m
02-12-2008 11:18:30
Famous last words.
betajaen
03-12-2008 20:41:20
Okay chaps. I've finished off the Ogre renderer and the first version of OgreCake. There is a bug I found with the Real4/NxQuat/Matrix44 quaternion code, so I've used matrices in the Ogre renderer instead. Apart from that it should be good to go.
How about a morning release tomorrow then?
xadh00m
03-12-2008 21:08:09
How about a morning release tomorrow then?
Sounds very good.
Do you have a roadmap for the character system in mind?
xad
nargil
03-12-2008 21:08:19
nah... we don't want it xD
betajaen
03-12-2008 21:54:34
Do you have a roadmap for the character system in mind?
I'm going to be a little busy this month. So I'll have to scale back my work with NxOgre a bit. However it is my only priority.
@Nargil
Fine, I'll delete it then.
mcaden
04-12-2008 07:24:11
so...sounds like everything I need except the character system is in atm?
woot!
betajaen
31-01-2009 18:45:02
WOO!
Spent first day in weeks on this code. I decided to work on the new "Volume" class. Which is the new name for triggers. I wanted to emphasise that it doesn't have to be for detection, but can be used for other things - like bouyancy, reduced gravity, etc. Providing you can write the code in the callback.
void myClass::createVolumes()
{
RigidBodyDescription description;
description.mVolumeCollisionType = Enums::VolumeCollisionType_All;
Volume* volume = mScene->createVolume(new Cube(10), Matrix44(0, 5, 0), this, description);
}
I've also simplified the callback system. The class is called "Callback", and contains every virtual function for any class that requires a RigidBody/Scene callback. As they are virtual (and not pure virtual), you can pick and choose which types of events you want to watch.
In the case of the Volume class it goes:
class myClass : public NxOgre::Callback
{
void createVolumes();
void onVolumeEvent(Volume* volume, Shape* volumeShape, RigidBody* rb, Shape* rbShape, int Event)
{
if (Event == NxOgre::Enums::VolumeCollisionType_Enter)
{
dance();
}
}
};
Anyway, I have tomorrow off as well. So I can work on it further.
Also; I need to look into micro-releasing, or having some sort of secondary SVN.
betajaen
03-02-2009 20:50:51
Okay, Volumes and Callbacks seem to be working.
But I have found a bug with PhysX or NxOgre, a really really strange one that corrupts pointers unless, you cast the NxShape into a more specific one (NxBox, NxSphere, etc.). Either way; until the bug is found the callback code has quite a few if statements than I would of preferred.
Some code!
mVolume = mScene->createVolume(new Box(10), Real3(0, 5, 0), this);
void onVolumeEvent(Volume* volume, Shape* volumeShape, RigidBody* rigidBody, Shape* rigidBodyShape, unsigned int collisionEvent)
{
if (!rigidBody->isDynamic())
return;
Actor* actor = static_cast<Actor*>(rigidBody);
float y = (9.81 * actor->getMass()) // counteract gravity
+ (-actor->getLinearVelocity().y * actor->getMass()) // counteract vertical velocity
+ (10 - actor->getGlobalPosition().y * actor->getMass()); // Add some force to move it to the top
actor->addForce(Real3(0, y, 0), Enums::ForceMode_Force, true);
}
Wretched_Wyx
08-02-2009 10:25:08
Great to see you're back on the NxOgre wagon after having been so busy!
I myself have just started toying with NxOgre again, which is something I've been looking forward to. It's been a few days- what are you working on (relating to NxOgre) right now?
betajaen
08-02-2009 12:24:30
I was in BloodyCake this morning and last night; nothing really to with NxOgre. I was finishing up the code SmartFont and SmartOverlay, so I could debug a few things. I do remember checking to see if Sphere triggers work though.
spacegaier
08-02-2009 12:54:30
Hi betajaen,
is there a way to get the newest version of NxOgre (with the VolumeCallbacks)? I just found the zipped older versions (1.5.2) or did you update them with the new code? Is there a public SVN directory somewhere?
betajaen
08-02-2009 16:00:39
Just my harddrive.
I'm in the middle of re-writing the NxOgre wiki again, which will be on a new server - which I've yet to move over. One of the first acts of the setting up the server; I shall put up a Bloody Mess SVN branch up on it.
spacegaier
08-02-2009 16:15:13
Could you perhaps make another new zipped version, so we can play around with the new CallbackSystem? With this implemented, I should have anything to start my new little game. It just needs actors and triggers/callbacks. Would be great!
Wretched_Wyx
09-02-2009 11:02:47
I relate this to my noobiness, but alas:
I was previously working with NxOgre 1.5.2, worked great. Well, had some troubles with my timing system and figuring out how to update NxOgre properly. I'm using a slightly modified version from the article "Fix Your TimeStep!" (Gaffer). I "think" I got that squared away, but until I get more timing related stuff in there, I won't be able to compare and be SURE that NxOgre is updating at say, 40 time per second, or rather the tick rate I have set for the rest of the systems.
Anyway. I moved to 1.0'22 today. Took a bit of work changing paths in the NxOgre solution, but it compiled fine after that. Erm, I had the latest PhysX SDK installed, and folder paths changed a bit. So using that handy batch file didn't prove so handy. Of course that's always an easy fix.
Now, for some reason (and this is my main problem) when I compile my app, or rather my solution (which is a lib, and then an exe)... the "demo" project which should only be spitting out an exe, is now spitting out lib and exp files. Move back to NxOgre 1.5.2, this doesn't happen. Move back to 1.0'22, there it is again! I've run into this once before, I just forgot how to fix it. But since it only happens when using NxOgre 1.0'22, I assume it's in there somewhere. Though, perhaps in your "personal" version that you're working on, you don't have this problem and as such this whole deal can be disregarded.
Now a couple other questions, and I will be ashamed if these have already been answered (I looked, but not *too* hard):
NxOgre log files- How can we disable, or change the output path?
Updating NxOgre/PhysX- I'd really like to just be able to say "update" when I want, and have NxOgre update, without passing in values or anything. I'm still learning, and modifying my timing system as I go, but so far none of the other systems need a value passed in. I've yet to work on the interpolation bit, as that sort of confuses me (per the Gaffer article at least). It seems easy to interpolate between previous and current x,y coordinates, sure... but Vector3 and what not seems like it gets more difficult. So perhaps eventually I'll need to pass in some sort of value to other systems, but right now I'm updating systems at a fixed rate of 40 ticks per second and it works great. Once I threw NxOgre in there, and checked out a few hundred boxes falling... choke city. Everything else updated fine, NxOgre not so much. The weird fix was changing all the timing to 1to1... in my case, this meant everything updated as fast as possible. NxOgre worked great then, everything else... not so much.
Now sort off-topic... I've yet to really dive into them yet, but those Nvidia PhysX tools, the plugins for Max/Maya- seem pretty fancy. What sort of options do we have for utilizing them in conjunction with NxOgre? Rather, any future plans on that end?
betajaen
15-02-2009 10:05:49
NxOgre log files- How can we disable, or change the output path?
Yep, you can change the filename in the PhysXParams; or you can disable the log via there too. You can also create a class and inherit from NxOgre::ErrorReporter (I think) and redirect all NxOgre errors into your code.
Updating NxOgre/PhysX- I'd really like to just be able to say "update" when I want, and have NxOgre update, without passing in values or anything. I'm still learning, and modifying my timing system as I go, but so far none of the other systems need a value passed in. I've yet to work on the interpolation bit, as that sort of confuses me (per the Gaffer article at least). It seems easy to interpolate between previous and current x,y coordinates, sure... but Vector3 and what not seems like it gets more difficult. So perhaps eventually I'll need to pass in some sort of value to other systems, but right now I'm updating systems at a fixed rate of 40 ticks per second and it works great. Once I threw NxOgre in there, and checked out a few hundred boxes falling... choke city. Everything else updated fine, NxOgre not so much. The weird fix was changing all the timing to 1to1... in my case, this meant everything updated as fast as possible. NxOgre worked great then, everything else... not so much.
Generally, if you let NxOgre handle time itself, and set it up to use the accumulator and all the bodies use the interpolation method, then you won't have any problems. If you run at a un-expected framerate; 40hz in your case. Make sure NxOgre knows about it, because it will tell PhysX it's running at 60 - hence the weirdness.
Now sort off-topic... I've yet to really dive into them yet, but those Nvidia PhysX tools, the plugins for Max/Maya- seem pretty fancy. What sort of options do we have for utilizing them in conjunction with NxOgre? Rather, any future plans on that end?
They generally use the NxuStream2 code which I detest; For meshes you can use your existing Ogre tools and use flour to convert them, for editors and other things. There have been a few things posted in the past you can have a look at.
betajaen
15-02-2009 10:12:02
Well, I've had some free-time again, so I've started work designing and writing the "Renderable" class.
The Renderable class is very much like the Ogre ManualObject and Ogre SimpleRenderable class. It's an interface for NxOgre to stream vertices and indicies to, from PhysX or itself. It has a multi-use and can be used with the DebugRenderer, Cloth, SoftBodies and Fluids. As it's rendersystem specific, only the functions are defined in NxOgre, but the implementation is done in the RenderSystem.
This is the intended use of it with Ogre:
OGRE3DRenderable* debugRenderable = new OGRE3DRenderable(NxOgre::Enums::RenderableType_VisualDebugger);
mWorld->setVisualDebuggerMesh(debugRenderable);
mWorld->setVisualDebugger(NxOgre::Enums::VisualDebugger_ShowAll);
It will be similar in use when cloth, softbodies and fluids are implemented.
betajaen
15-02-2009 19:20:41
Huzzah!
mVisualDebuggerRenderable = new OGRE3DRenderable(NxOgre::Enums::RenderableType_VisualDebugger);
mVisualDebugger->setRenderable(mVisualDebuggerRenderable);
mVisualDebuggerNode = mSceneMgr->getRootSceneNode()->createChildSceneNode();
mVisualDebuggerNode->attachObject(mVisualDebuggerRenderable);
mVisualDebugger->setVisualisationMode(NxOgre::Enums::VisualDebugger_ShowAll);
...
void frameStarted(const Ogre::Real& r)
{
mTimeController->advance(r);
mVisualDebugger->draw();
mVisualDebuggerNode->needUpdate();
}
Most likely, I'll release this version when I find the password to NxOgre.org - since I recently moved to a new computer.
spacegaier
16-02-2009 16:02:02
I'm really looking forward getting a new version to play around with!
betajaen
16-02-2009 16:21:44
I started on a particle system last night, and want to create a CircularBuffer class to try out a few ideas I have. Hopefully using the Renderable class; I can create 1000's of RigidBodies and render them in one batch.
betajaen
18-02-2009 17:36:18
Still working on the ParticleSystem. Added a few more classes; ParticleEmitter, ParticleDrain.
The most interesting class is the "RestingParticle", which is a union of a 4x4 matrix for position and orientation of the particle, as well as death time. The idea up 10% of the particles can be represented by resting particles upto x seconds after their death. This allows the original particle to be re-used by something else. My original thought when I created the class was a tree with falling leaves; all the leaves that are now stuck on the wet ground are resting particles which slowly fade out, but since the number of particles that are sleeping are zero, the amount of leaves falling are consistent. I even plan to make a small demo of this.
Also; I wrote a Python script to run through the NxOgre source code, and create "NxOgre.h" file for me - so I don't have to remember to add the #include everytime I add a new header file to NxOgre.
spacegaier
18-02-2009 18:10:08
Sounds great! Can you already say, when a new zipped version will be available?
betajaen
18-02-2009 18:55:17
If you want it now; then I can FTP to NxOgre.org it tomorrow. But it'll be an un-official release, with no support or thread.
spacegaier
18-02-2009 19:18:58
Well, I doesn't excactly need to be tomorrow, but it would be nice to have a version this sunday to play around with new callback system (at least I hope to have some sparetime this sunday).
betajaen
19-02-2009 09:42:04
spacegaier
20-02-2009 19:58:14
Could it be that you use VisualStudio 9.0? Because when I try to open the .vcproj I get an enumeration error for the value 9.0 as it is not in the range from 7.0 to 8.0 that probably stand for the versions.
Could you provide another archive that can be opened with older versions?
betajaen
20-02-2009 20:19:39
Yeah. I forgot to mention that, I switched to Visual Studio 2008 when I bought my new computer.
However; you can open the VC9 solution file in notepad and just change the version numbers, it'll work in VC8 if you use another solution file for reference.
I should write a python script to make one for me though.
[Edit]
Wrote the script.
spacegaier
20-02-2009 21:01:04
Okay, changing the version number in the .vcproj files did the trick. However, you should think about a way to make it easier for the not so experienced user in the final releases to use it with their version, so either include your script, that can dynamically insert the needed value or provide several different archives for different settings.
But that is something for the final releases not for small testing versions like this one.
spacegaier
20-02-2009 21:09:29
Arghhh..building the debug versions works fine, but he woun't do it with the release ones. He states many times:
- Fatal error C1038: File (precomiled header file) could not be found: "Release\NxOgre.pch": No such file or directory [/list:u]
And at the end, he states for nedmalloc.cpp:
- 1>.\source\nedmalloc.cpp(951) : fatal error C1010: Sudden end of file while searching for the precomipled header. Did you possibly forget to insert "#include "NxOgreStable.h"" in the source code?
[/list:u]
betajaen
20-02-2009 21:34:53
Hmm. I haven't used release in a long time. Apart from the automatic linker debuggy bits; Bloody Mess doesn't do anything special in debug.
I'll try and fix it and post a new copy for you.
spacegaier
20-02-2009 21:39:39
And yet another thing. I have a simple test case for NxOgre (just a plane and a cube) that worked fine in the older version.
Now I just replaced the older NxOgre version with the newer one and voilà: I get four linker errors (concerning the creation of these objects afaik). Is this the normal behaviour? I guess not. I also realized that there is no Ogre3DRenderSystem.dll or whatever. Shouldn't there be something like that (as it has been in the versions before)?
PS: I get no errors when building NxOgreOGRE3D, but there is not DLL, just a NxOgreOGRE3D_Debug.lib
betajaen
20-02-2009 21:43:14
No, it's a static library and brought into your application automatically. Don't worry; it's under the MIT licence and I allow you to do that.
I got NxOgre.dll compiled, I'm now just working on the rendersystems and then test it all out in BloodyCake.
spacegaier
21-02-2009 16:09:49
But building the NxOGRE3D project should result in a DLL, shouldn't it?
betajaen
21-02-2009 19:52:36
Nope, just a lib. It's in the sdk folder, along with the headers and other libs and dlls you should use.
spacegaier
22-02-2009 18:07:23
Thanks for the help. I got it now running, the Volumes and their callbacks as well as the VisualDebugger. No bugs or problems so far. Excelent work!
betajaen
22-02-2009 18:47:10
Ahh, brilliant! I was a bit worried about the Renderable code.
The next release will be easier for VC8 users, so you won't have to go through that annoying conversion again.
Hi,
I think it hasn't been asked yet (sorry if I'm wrong). Do you plan to implement fluids, cloth and soft bodies in BloodyMess (and possibly in the Ogre3DRenderSystem)?? When looking at the code it seems that parts were realised in Bleeding, right? Oh, and if there are any plans, may I ask for a rough estimate on how long this will take?
Many thanks,
fsm
betajaen
24-02-2009 19:59:30
Bloody Flour
Started on another project. "BloodyFlour", intended for Bloody Mess. It will be written alongside the BloodyMess resource system and mesh loading/saving classes and functions.
It has some changes though.
- It still has a command line interface.
- It will have a several GUI interfaces for different utilities/functions you want; instead of using the command line. It uses wxWidgets.
- It uses a sub-project "libFlour" to hold all of the processing classes and core code. It is under the MIT licence, which you can include in your application. If you want to cook meshes or do flour like things without flour.
spacegaier
25-02-2009 18:10:06
@betajean: I think I found a bug in the VisualDebugger.
I implemented a little toggle part for VisualDebugger: I have bool variable that indicated whether the VisualDebugger should be visible or not. This variable can be toggled by keyboard input. In my main loop there is an if statement:
if(m_bVisualDebugger == true)
{
m_pVisualDebugger->draw();
m_pVisualDebuggerNode->needUpdate();
}
My keyhandling function that is relevant looks like this:
if(m_pOgreFramework->m_pKeyboard->isKeyDown(OIS::KC_V))
{
m_bVisualDebugger = !m_bVisualDebugger;
m_pVisualDebuggerNode->setVisible(m_bVisualDebugger);
}
I thought that now it should work, but it doesn't. As soon as I press V to to switch the VisualDebugger on, I get a runtime error.
Details: nxogrememory.cpp line 158 in this function:
void Memory::copy(void* dest, const void* source, size_t length)
Solution: Before starting my main loop, it entered this:
m_pVisualDebugger->draw();
m_pVisualDebuggerNode->setVisible(m_bVisualDebugger);
So, I let the VisualDebugger draw one time and immediately set it to invisible.
spacegaier
25-02-2009 18:36:10
I found something else: I'm not able to build NxOgre in Release mode?!? Should that work or not?
- 1>..\source\NxOgreWorldPrototype.cpp(26) : fatal error C1083: File (precompiled header) cannot be opened: "Release\NxOgre.pch": No such file or directory
1>NxOgreWorldDescription.cpp[/list:u]
I said VisualStudio not to use precomiled headers and it worked, but it has also worked in debug mode with precompiled headers!
VisualStudio also stated that NxOgreStable.h could be missing in nedmalloc.h (or something similar; can't reproduce it anymore, due to problems I'm encountering now with the precomile headers option).
betajaen
25-02-2009 19:10:25
To be honest, I haven't used the Visual Debugger that much. After it was drawing; I didn't bother binding some key to turn it on or off. I'll replicate your problem and come up with a better solution.
Here is Bloody Mess (without BloodyCake) with the Python built VC2005 solution files for you. It compiles in Debug,Release, DLL and static.
http://get.nxogre.org/releases/Bloody25Feb2009.zip
[Edit] I realised I just uploaded it with the python script to generate a NxOgreH file in the post compile script. If you don't have Python installed, you'll get an "error". I won't worry about it, NxOgre.h already exists.
spacegaier
25-02-2009 19:16:21
I have Python installed and building worked (VS stated some errors, but however everything is there and runs).
betajaen
25-02-2009 19:21:52
Errors? Surely you mean warnings? I get a few of those, but no Errors.
spacegaier
25-02-2009 19:24:19
I'll check it again, but I'm quite sure hat there were some errors (at least for GLUT). Give me some minutes.
And: Is there a way to make a OGRE3DBody static, so that it doesn't move anymore (setting mass to zero didn't work as it used to in NxOgre 0.9 afaik).
betajaen
25-02-2009 19:27:43
No. You have to use a StaticGeometry and create the related scene nodes yourself. I suppose I could create a function in OGRE3DRenderSystem if the demand is high enough.
spacegaier
25-02-2009 19:28:16
Okay, I just build NxOgre in release mode again and there was one error (although it is not important):
- 1>D:\BloodyMess\build\msvc\source\NxOgre.h
1>D:\BloodyMess\build\msvc\source\NxOgreConfiguration.h
1> 2 File(s) copied.
1>The system can't find the stated directory.
1> 0 File(s) copied.
1>Project : error PRJ0019: A tool has returbed an error code from the following source: "Postbuild event is proceeded..."[/list:u]
(It's translated from my german output, so the excact wording could be different in your IDE...)
spacegaier
25-02-2009 19:32:00
There is no class StaticGeometry. Did you mean SceneGeometry or is StaticGeometry still to come?
betajaen
25-02-2009 19:32:28
It couldn't copy the DLL into the cake directory, as far as I can understand. No biggie.
I meant SceneGeometry.
spacegaier
25-02-2009 20:11:40
Okay, I tried implemeting a ramp, by taking a box and rotating it a bit. But I found no way to give a SceneGeometry a visual represetation. In addition, it get an linker error when trying to run this:
Shapes shapes2;
shapes2.insert(new NxOgre::Box(Real3(12, 0.4, 4)));
shapes2[0]->setLocalPose(Matrix44(10, 10, 20, 20, 30, 10, 20, 10, 20, 10, 20, 10, 20, 12, 12, 12));
m_pSceneGeom = m_pScene->createSceneGeometry(shapes2, Matrix44(Matrix44::T_Identity));
The problem here is the third line.
betajaen
25-02-2009 21:07:25
Okay, I tried implemeting a ramp, by taking a box and rotating it a bit. But I found no way to give a SceneGeometry a visual represetation. In addition, it get an linker error when trying to run this:
Shapes shapes2;
shapes2.insert(new NxOgre::Box(Real3(12, 0.4, 4)));
shapes2[0]->setLocalPose(Matrix44(10, 10, 20, 20, 30, 10, 20, 10, 20, 10, 20, 10, 20, 12, 12, 12));
m_pSceneGeom = m_pScene->createSceneGeometry(shapes2, Matrix44(Matrix44::T_Identity));
The problem here is the third line.
I'll have a look at that linker error, but try it with no pose to start off with. As for visualisation, your code it supposed to handle that. A SceneNode/Entity where that ramp would be.
spacegaier
26-02-2009 07:59:53
1. Wouldn't it be possible to add a visualization directly in the SceneGeometry class (or at least offer the possibilty), because I can hardly imagine a case, where you only want a non-visible SceneGeometry.
2. Can this SceneGeometry also be moved or how would I realize the following:
- I want a ramp that doesn't move at the beginning (so a SceneGeometry), but while the application runs, this ramp should sometimes changes its position fluently (meaning: I don't want to delete the existing and create a new at a different position, but I want to fluetly let it fly somewhere, land and be static again).[/list:u]
3. I had a quick glance at the KinematicActor and its Controller. Could it be that the only (big) difference between a KinematicActor and a Character is the fact that the one is visualized, the other not?
betajaen
26-02-2009 09:21:22
1. Yes, you inherit from SceneGeometry. Much like how OGRE3DBody inherits from Actor.
2. Nope, never moved.
3. Nope, Characters implement stepping and collision callbacks, where as KinematicActors do not.
If you want things visualised you will have to make the class and inherit from the appropriate NxOgre class.
spacegaier
26-02-2009 09:33:02
Okay, but how can I realized my point 2? Is there a way to create a NxOgre object that can move, but can also be set to static temporarily (e.g. telling an Actor not to move)?
betajaen
26-02-2009 10:02:06
Use a KinematicActor.
spacegaier
26-02-2009 17:40:59
Okay, I just wanted to try that, but I found two things:
1. Concerning the IntelliSense problem. It works now almost everywhere but only as long as you don't have that:
NxOgre::Shapes shapes;
After defining a Shape* array (meaning your Shapes), IntelliSense dies...
2. I tried to work around that problem, by not using a whole Shape* array, but a single one (as createKinematicActor also takes this as a parameter). But I couldn't find there anything similar to the insert() method of a Shapes. insert() only wants one parameter (a Shape*), whereas every function of SNxOgre::Shape needs more (e.g. a Shape and a RigidBody). So this does not work:
NxOgre::RigidBodyDescription kaDescr;
kaDescr.mType = NxOgre::Enums::RigidBodyType_Geometry;
NxOgre::Shape kaShape;
kaShape.assign(new NxOgre::Box(5, 5, 5), RigidBody());
m_pKA = m_pScene->createKinematicActor(kaShape, Matrix44::T_Identity, kaDescr);
Problems: assign() is virtual (NxOgre::Shape is abstract) and RigidBody() is protected!
-> Could you please give a code example of how to create a static, kinematic actor?
betajaen
26-02-2009 18:35:51
Of course that code snippet doesn't work. It doesn't make any sense.
These are various ways of creating a kinematic actor.
mScene->createKinematicActor(new Box(1));
ShapeDescription shapeDesc;
shapeDesc.mLocalPose.fromXYZ(10,10,10);
mScene->createKinematicActor(new Box(1, shapeDesc));
Shapes shapes;
shapes.insert(new Box(1));
ShapeDescription shapeDesc;
shapeDesc.mLocalPose.fromXYZ(0, 2, 0);
shapes.insert(new Box(1, desc));
mScene->createKinematicActor(shapes);
And don't make "Shapes" a pointer, it's written in a special way that it wasn't meant to be one.
spacegaier
26-02-2009 20:38:52
Okay, works now (but probably, I will still ask a question tomorrow concerning them). However, thanks so far!
New problem: Your Real3 class could need some more operators. At the moment, this results in a compiler error:
Real3 res = Real3(1, 1, 1) + Real3(2, 2, 2);
The same goes for Int2, Int3, Int4, Real2 and Real4.
betajaen
26-02-2009 21:15:39
Yeah. I may add them, but Real3 aren't meant to be a real Vector class but more or less a struct of three floats.
spacegaier
26-02-2009 21:22:57
I would be really handy e.g. in this case:
m_pKA->moveGlobalPosition(m_pKA->getGlobalPosition() + Real3(-5, 0, 0));
betajaen
26-02-2009 21:37:54
Yeah. I suppose.
spacegaier
28-02-2009 19:28:27
Little update on the problem with the VisualDebugger:
The "solution" I posted
here only works in DebugMode!
In ReleaseMode it crashes at runtime when ordering the VisualDebugger to draw itself once before entering the main loop. The IDE jumps to ogre3drenderable.cpp line 220:
vColBuf->unlock();
Commenting out this line in Release does the trick for both, Release and Debug!
betajaen
28-02-2009 19:54:41
Interesting. I'll try out your fix.
Betajaen Hello, you first want to congratulate the Nx Bloody Mess is best for my vercion of emboltorio. Now, I have a few queries that I hope you can answer ...
1) "shape = new NxFish::Capsule(...)" I did not go well, said uqe can not instantiate an abstract class. It is right what I mean?
2) "mNxScene->createKinematicActor" is for geometries that do not move, and if I wanted something dynamic? Thank you and I hope your answer.
spacegaier
02-03-2009 19:24:17
1. What is NxFish?
2. m_pScene->createActor(...); Via this method you create a new actor.
3. KinematicActors can be moved via setGlobalPosition();
Hey, if you pardon, I'm wrong. I do not speak English and I'm not very good translation. I promise not to distract. The NxOgre I like, but there are things that can not understand. Thanks for your reply, I hope I can help again with the following query: I have the following code is ejuta good but not VisualDebugger shows me no body (unless the entity ogre obvious) I'm doing wrong?
//Load Grafica
this->scene = new OgreMax::OgreMaxScene;
this->scene->Load(fileToLoad, renderWindow,OgreMax::OgreMaxScene::SET_DEFAULT_LIGHTING, mSceneMgr, 0, this);
GetMeshAnimations(this->scene->GetSceneManager()->getEntity("casual01_m_highpoly"));
//Load fisica
Proto = new OGRE3DBodyPrototype();
Proto->mType = NxOgre::Enums::RigidBodyType_Dynamic;
Proto->mSceneManager = mSceneMgr;
Proto->mEntity = this->scene->GetSceneManager()->getEntity("Hombre01");
Proto->mNode = this->scene->GetSceneNode("Hombre01",false);
Ogre::Vector3 position = this->scene->GetSceneNode("Hombre01",false)->getPosition();
Proto->mGlobalPose.fromXYZ(position.x,position.y, position.z);
Proto->mMass = 100;
NxOgre::ShapeDescription shapeDesc;
Ogre::Real radio=this->scene->GetSceneManager()->getEntity("Hombre01")->getBoundingRadius()/2;
Ogre::Real alto=this->scene->GetSceneManager()->getEntity("Hombre01")->getBoundingBox().getSize().y ;
shapeDesc.mLocalPose.fromXYZ(position.x,position.y, position.z);
shape = new NxOgre::Box(radio,alto,radio,shapeDesc);
Proto->mShapes.insert(shape);
body = new OGRE3DBody(Proto,mNxScene);
I use the OgreMax to load a scene and its animation (in this case a person) and then use the OGRE3DBody of NxOgre for the physical part. Is that correct?
betajaen
03-03-2009 15:36:39
You shouldn't need to use a RigidBodyPrototype those are internal classes. Descriptions are for public use.
As your using your own Max loader to pre-create SceneNodes and Entities; You should make your own Body class, that fits into your application better. You can look at the OGRE3DBody to see how I did it, then just apply similar code to your application.
Thanks ... problem solved ... I now have another issue when I use a dish, I get an error, here are the details:
Codigo:: shape = new NxOgre::Capsule(radio,alto,shapeDesc);
Error: error C2259: NxOgre:Capsule: can not instantiate an abstract class
I'm wrong or something is a bug of NxOgre? Thank you.
betajaen
16-03-2009 17:12:16
Been pretty busy lately. However I spent my weekend on it. So in short:
- All shapes except for wheels and heightfields are implemented and re-implemented.
- Convex and Triangle Meshes implemented.
- ManualMesh for Convex cooking implemented
- MeshManager class implemented.
- ResourceSystem implemented.
- Archive concept implemented
- Windows file/archives implemented.
- Memory resources and archives implemented.
After some testing and some optimisation, the end of the week or earlier, it will be released as version 1.5.3
betajaen
17-03-2009 23:15:25
Probably coming at the end of the week, or so.
scratchyrice
24-03-2009 11:17:36
Awesome! Cant wait!
Is there any news on when cloth and ragdolls will be implemented? I do not need it right now, But i will do in the future.
Cheers
Scratchy
betajaen
24-03-2009 11:48:37
I have plans to do them, but I cannot give out a time frame.
ronbunny
25-03-2009 01:25:53
hi
anyone know where can i get a copy of bloody mess as i could not find the get.nxogre.org site
Illidanz
25-03-2009 08:46:06
hi
anyone know where can i get a copy of bloody mess as i could not find the get.nxogre.org site
viewtopic.php?f=6&t=9562
ronbunny
26-03-2009 01:39:56
can anyone help me with the problem
after adding this line into my codes, my exe will auto exit after i choose the rendering system
mWorld = NxOgre::World::createWorld();
SceneDescription sceneDesc;
sceneDesc.mGravity = NxOgre::Real3(0, -9.8f, 0);
sceneDesc.mName = "Hello";
mScene = mWorld->createScene(sceneDesc);
there is also an error when i compile my bloodymess
Error 2 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."
Can anyone tell me whether the problem was caused by not compiling successfully or there is something i missed out?
scratchyrice
26-03-2009 09:24:38
I think you have to create the render system before any scenes.
Cheers
Scratchy
scratchyrice
26-03-2009 09:29:45
Error 2 error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."
D/w, The lib still compiled.
Cheers
Scratchy
betajaen
26-03-2009 10:31:53
You don't have to, but the OGRE3DRenderSystem does require the scene pointer, so naturally you would create it after the Scene.
And which RenderSystem are you talking about? NxOgre's or Ogre's? Although they have the same names, they are very different things.
ronbunny
27-03-2009 09:32:54
hi can anyone tell me how do i use the 4th parameter from createbody?
i have this error when i input this line of code
Error 5 error C2664: 'OGRE3DRenderSystem::createBody' : cannot convert parameter 4 from 'const char [9]' to 'const NxOgre::RigidBodyDescription &' c:\documents and settings\ronson\desktop\simpleogre\simpleogre\main.cpp 371
mCube = mRenderSystem->createBody(new NxOgre::Box(1, 1, 1), NxOgre::Real3(0, 20, 0), "box.mesh", "mass: 10");
is there anything wrong with this line? And can anyone teach me how do i attach actor to bloodymess?
i did something like that in the past for actor collision
PlayerGroup = Application::mPhysicsScene->createActorGroup("player");
mCube = mRenderSystem->createBody(new NxOgre::Box(1, 1, 1), NxOgre::Real3(0, 20, 0), "box.mesh", "mass: 10, group: player");
PlayerGroup->setCollisionCallback(MouthGroup, NX_NOTIFY_ALL, true);
PlayerGroup->setCallback<T>(this, &T::function, &T::function, &T::function);
btw is there any tutorial about actors?
betajaen
27-03-2009 09:46:04
Yes, theres a
full wealth of tutorials written by Spaciergaier on the Wiki, and you can't use strings in params anymore in BloodyMess.
alienskull
29-03-2009 15:06:25
Instead of using new box()NxOgre::Actor* actor = physicsScene->createActor(new NxOgre::Box(1,1,1)); how do I use your newly implemented convex and triangle meshes?? I'm using version 1.5.3.
I havnt used NxOgre in awhile but I believe there is auto-cooking involved or something... I could use a refresh course.
spacegaier
29-03-2009 15:10:42
Convex and triangle shapes aren't in yet (in the version that can be downloaded). However, afaik they are already implemented and will be released in the next version that is said to come the next days (or even today as betajaen said that it will probably happen this week).
alienskull
29-03-2009 15:18:19
ahh yes.. i guess im really using 1.5.2... oops
i guess i should read the release notes more carefully...
he just templated what he was going to put in the next release without really filling it in... lol
1.5.3 - Released on DD-MM-YYYY, at URL
Authors:
[Betajaen] Robin Southern, Lead developer of NxOgre
Summary:
Text.
Changes:
[1] Rearranged the folder and file structure of Bloody Mess, to allow better support with different
compilers and platforms..
Warnings:
[1]
ronbunny
30-03-2009 18:07:07
Can anyone write a simple tutorial on actors? maybe just a simple collision detection test as i am used to pass version of NxOgre.
spacegaier
30-03-2009 18:46:46
alienskull
03-04-2009 04:00:07
With Ogre's new
static linking exception to the LGPL is there any plans to do a similar thing with this Bloody Mess?
It would definitely cut down on the dll hell whole around any executable I make.
betajaen
03-04-2009 08:58:29
No, I'm happy with the current licence. You can still static with NxOgre, you just have to follow the original LGPL agreement.
betajaen
04-04-2009 09:15:35
I'm releasing Bloody Mess 1.5.3 this weekend. I'm just cleaning up the Heightfield code, and finishing up my implementation of the RemoteDebugger class, and it should be good to go.
I may even write a quick tutorial on the wiki for it.
Hello Gentlemen,
After reading through much of the Bloody Mess development blog, I'm in need of your expert assistance. I have downloaded the new version that betajaen posted yesterday, and got it compiling (btw, the vs9 sln file has about 50 warnings, an external tool error, and if you try and compile it as a static library rather than dll, it won't work without some tweaking of the paths). The feature set and underlying structure looks really cool; however, it looks like it is still heavily in development, with a not quite 100% stable release with all of the features of previous versions. I downloaded the Bleeding versions from betagaen's link in the forum, and got the latest one (T5) compiling, but using the only good tutorial I could find on the wiki, one of the functions throws an error using the exact code that's in the tutorial. So my question to the nxOgre experts...what's the last truly stable version with the most features? Also, is there documentation or tutorials for all of it's main features someplace, or are they no longer accessible now that half the links on the wiki are broken for nxOgre with betajaen's domain being down? I'd like to use nxOgre to teach my roughly 100 students game physics (making you a little more famous!), and would like to make it as painless on them as possible, but I need something stable with documentations. I really need your advice... Would you recommend a different physics wrapper until nxOgre's Bloody Mess version is complete? Should I just have the students use PhysX directly with no wrapper? What's the best way to learn bleeding or bloody mess? Your help is much appreciated!
P.S. I'm posting this here as I believe many of the people that have been reading through your current development blog for the first time are probably all asking the same questions -- and there is no answers in the FAQ posted to the forum.
Thank you.
betajaen
05-04-2009 17:50:59
Bleeding; NxOgre 1.0.22T5 is the most feature packed and is quite stable.
Bloody Mess; NxOgre 1.5.3 is not so feature packed (quite a bit is missing) but it is more stable.
Really, it's up to you but I would go with 1.0.22T5. Bloody Mess has had a few changes in interfaces, and most likely will change in the next release.
As for documentation currently it's a bit of a mess at the moment with the NxOgre website down. I may be able to put up a directory containing the html of the old website. But it wouldn't be very elegant. It has my short guide to NxOgre (Bleeding), and lots of other little things.
betajaen
05-04-2009 18:14:37
Success. I found the original shortguide I wrote for 0.9. It should still apply to Bleeding, and it's pretty well drafted. It only goes up to Actors, but combined with Cake. It should be a good start to work from.
http://www.nxogre.org/documentation/bleeding/
I read the shortguide for 0.9 that you posted. Everything up to Actors makes much more sense now -- you did a nice job on the guide. It would seem the next logical step would be to create bodys for actors so there is something on the screen. I found code for version 1.0.22T5 in the forums to create a body for an actor, and got a basic cube on screen myself (which falls like a feather). I'm ready to digest more explanation on bodies -- how they fit together with Ogre, what can and can't be done with them, etc., then move onto more advanced uses of the nxOgre such as collision detection, etc. Any more guides you've written?
Where should I go next?
Thanks again!
betajaen
06-04-2009 09:29:02
Unfortunately without putting up the old Wiki there isn't anything. I found the cached html files for the wiki, which I can put up online, but their would be no clever index, and some of the images and styles won't work. I can put those up, but they are no where good as the old guide. At this point BloodyMess has more documentation at the moment. Apart from it not having a joint system, if you use only the basics BloodyMess is better to learn from.
For anyone else who likes the guide; I've started to rewrite it for BloodyMess.
A few posts on the forums refer to a document you used to host that explained how to properly derive a new class from the body class of release T5. Any chance you've still got this someplace? I think I should be able to pick up triggers for Bleeding from the Bloody Mess tutorials on the main Ogre wiki, as they look to work similarly between the versions (just in case anyone else is following this and is also looking for more info). From what I've got working so far, I'm very impressed with NxOgre -- I still have a lot to learn though. I brought my implementation from the weekend to work with me this morning and have one of my students working with it already. He was so happy to have basic physics he hugged me when he saw it. He'd been waiting to get physics integrated in for a while!
Thanks again!
betajaen
06-04-2009 18:44:01
A few posts on the forums refer to a document you used to host that explained how to properly derive a new class from the body class of release T5. Any chance you've still got this someplace? I think I should be able to pick up triggers for Bleeding from the Bloody Mess tutorials on the main Ogre wiki, as they look to work similarly between the versions (just in case anyone else is following this and is also looking for more info). From what I've got working so far, I'm very impressed with NxOgre -- I still have a lot to learn though. I brought my implementation from the weekend to work with me this morning and have one of my students working with it already. He was so happy to have basic physics he hugged me when he saw it. He'd been waiting to get physics integrated in for a while!
Absolutely. Here is a copy of all the HTML files and some diagrams that was on the Wiki. There is no styling or such, but the text is more important. There is also a slightly different version of the shortguide on there, I believe I was rewriting it when I was working on Bleeding. It should help.
http://nxogre.org/documentation/bleeding/old/
The file you want is; Inheriting_Actor_and_forcing_NxOgre_to_use_your_own_Body_type_class.html
betajaen
07-04-2009 09:54:28
I've been working on the documentation for the last couple of days and I decided to rewrite the shortguide for BloodyMess; Taking the same style of writing and humour and most of the cartoons (although I had to edit some of them).
So, this is a work in process right now but I'll be updating it every time I finish a chapter.
Betajaen's short guide to creating a Bloody Mess
Karan
08-04-2009 22:32:28
Are CompoundShapes not implemented yet? Haven't found anything like it in the code. I'm trying to upgrade from Bleeding (1.0.22T5) to 1.5.3 (in a branch...) and I wonder if I can do this in Bloody Mess yet:
NxOgre::CompoundShape* cs = new NxOgre::CompoundShape();
cs->add(new NxOgre::Sphere(BV3D::BLOBB_SHAPE_DATA[0][1]+0.05));
NxOgre::Sphere* upperSphere = new NxOgre::Sphere(BV3D::BLOBB_SHAPE_DATA[0][3]);
upperSphere->setLocalPose(NxOgre::Pose(0, 0.7, 0));
cs->add(upperSphere); //upper horizontal radius
mActor = mNxScene->createBody<NxOgre::Body>("blobb", cs, position, nrp, "mass:10");
betajaen
08-04-2009 23:11:37
It should be (it's called Shapes now), except I just looked in Scene again, and every rigidbody creating function except for Actor supports multiple shapes - Whoops.
If you want, I can run you through adding the function into Scene.
Karan
08-04-2009 23:47:46
Should it look like that?
Actor* Scene::createActor(Shapes shapes, const Matrix44& pose, const RigidBodyDescription& description) {
RigidBodyPrototype* prototype = NxOgre_New(RigidBodyPrototype)();
Functions::PrototypeFunctions::RigidBodyDescriptionToRigidBodyPrototype(description, prototype);
prototype->mShapes = shapes;
prototype->mType = Enums::RigidBodyType_Dynamic;
prototype->mGlobalPose = pose;
Actor* actor = NxOgre_New(Actor)(prototype, this);
NxOgre_Delete(prototype);
mActors.insert(actor);
return actor;
}
Can't test it yet because I've got some more conversion to do before my game compiles again...
betajaen
09-04-2009 00:10:39
Yep, exactly what I got. Make sure to add an additional createBody function in OGRE3DRenderSystem as well.
They'll be another release this weekend, that does modify the shape system again. It's back to functions for setting properties - so if your working on that right now, you may want to leave off. Spacegaier and I found a major cause of lag in this version too, I get ~600 FPS in Cake now, when it used to be 90!
Karan
09-04-2009 00:21:43
Ok, then I'll wait for that release. Do you plan more interface changes or will it become stable soon?
betajaen
09-04-2009 00:44:14
It's pretty stable now. It's just I wanted to make the shapes system more efficient.
betajaen
09-04-2009 14:39:11
I'll make an more official post when it's nearing completion, but I want to draw everyones eyes on the new documentation for BloodyMess. Apart from any technical documentation which will come separate and will be in a more serious tone but this is the shortguide, tutorial and walkthrough for BloodyMess. Anyone who wants to learn to use BloodyMess will have a chuckle doing so.
http://nxogre.org/documentation/bloodymess/
I quickly skipped ahead on the HeightFields section to the KinematicActor's section; I had a few ideas which I wanted to write down. I think it's hilarious that I could make something funny out of Newtons law's of motion.
asafdav2
13-04-2009 22:28:47
the first sentence in the Readme block of bloody mess documentation should probably be rewritten, currently it reads
When working with the Ogre parts of Bloody Mess, you will need at minimum you need at least a weeks worth of experience to work with Ogre and NxOgre
betajaen
13-04-2009 22:41:10
Took me three times to re-read it, until I got it. I'll try and remember to fix it when I have the file open again.
betajaen
15-04-2009 23:18:14
Update
I redid all shapes again. Nearly all of them have working functions now and are good to go. I had to re-implement the ShapeDescription class, but I've made it simpler. Instead of each shape having their own version. Only two shapes (will) have their own (HeightField and Wheel), the others just use the same version.
I started on Joints, and just finished filling out the SphericalJoint functions about 10 minutes ago.
I have made a huge change to the vector and math classes of it now. I've filled out the Real2, Real3, Real4 classes now, and are very much like the Ogre::Vector3 and NxVec3 classes; ability to do cross/dot products, vector multiplication/division/subtraction/addition, etc. I decided not to implement functions like "distance" or length that are in Ogre::Vector3. Real3's are just vectors only and are used for other things than coordinates.
I have re-written the Matrix44 class now, and made a Matrix33 class. I'm positive there is a bug in PhysX and quaternions; they just come out wrong every time.
Anyway; I'm planning to release my changes and additions during sometime this weekend.
betajaen
20-04-2009 11:45:18
I finished of the changes to the Shapes this weekend. I also implemented three of the major joints; Revolute, Spherical and Fixed and working on the D6 now. I've also rewritten the Real2, Real3, Real4 classes. Matrix44 is more prettier now and I think I got that quaternion bug squashed.
I did want it released yesterday, but I thought I would sneak in ray-casting, so it's now delayed a few days.
I'm doing some work now with Bloody Mess to try and learn it -- as it seems very promising. This may be a silly question...but in Bleeding release T5, the following could be done after creating an Ogre entity, and retrieving it's bounding box, to create a Body roughly the same as the entity:
NxOgre::Body *body = (Body*)mNxScene->createBody<NxOgre::Body>("box_body", new Cube(entityBounds.getSize()),
NxOgre::Pose(boxNode->getPosition(), boxNode->getOrientation()), nrp, "mass:10");
In Bloody Mess, I can get close by doing:
OGRE3DBody* mCube;
mCube = mNxRenderSystem->createBody(new NxOgre::Box(1, 1, 1), NxOgre::Real3(0, 1000, 0), "cube.mesh");
Ogre::Entity *ent2 = mCube->getEntity();
Ogre::AxisAlignedBox entityBounds = ent2->getBoundingBox();
ent2->setMaterialName("CubeMat");
It would seem logical to set the size of the box around the body to be the same size as the bounding box of the mesh. Any trick to doing this automatically when creating a body?
betajaen
25-04-2009 10:01:02
No, not automatically. You would have to create your own Body class and RenderSystem to achieve this.
The OGRE3DBody rendersystem is just merely an example or base framework for serious applications to base their code upon.
I guess this would be a good opportunity for me to make a feature request then!
there are no no formal docs yet on doing this with Bloody Mess that I've been able to find, I think recreating a rendersystem is beyond my reach at the moment with Bloody Mess.
I've posted the following to two new threads in the forum titled: [Bloody Mess] Important: Code Repository (Please Read!!) & [Bleeding] Important: Code Repository (Please Read!!) . I want to also post it here in hopes that the many users of NxOgre that keep up with this thread on a regular basis read this and help contribute:
---------------------------
Hello All,
I've been spending the last month working with NxOgre. NxOgre is a powerful wrapper for PhysX, but many times I've found myself very frustrated with its use! Documentation is minimal, and there are very few listings of full source to common problems available.
In an effort to help one another, and cut down on the number of questions, especially the simple ones that are asked over and over in the forum to betajaen and others, I'm creating this topic in hopes that the user community of NxOgre will help each other out and solve some of our biggest challenges with NxOgre. As anyone like myself studying NxOgre for the first time as of more recently has found out, there are many versions, and very little documentation on these versions. When reading through forum posts, most of our posts are our own specific questions of how to do stuff related to game development with NxOgre. Most of the time, we post a small slice of our code that we need help with (which 1,000+ other people before us have probably already implemented), then once we get help, we go back to coding, never posting the full solution to the problem. When reading through the forums, there is rarely any full solutions to major problems posted, just small code fragments where people ran into something they couldn't figure out themselves.
It would seem most of what you want to do with NxOgre has already been fully implemented by someone, who is using it right now in their games or other applications, but just hasn't posted their implementation. So the same problems occur over and over again...we continue to waste time trying to code the same solutions ourselves that someone else has already coded, tested, and is using. This is an inefficent waste of talent. Due to the lack of full documentation (which one must expect anyway when a solution of this magnitude only has a single developer, who has his hands full already coding NxOgre and trying to answer all our questions), it can take weeks or months, and many forum posts to work out a full solution of a class or classes to a single physics problem we want implemented in our games. Some of the most common problems we want to use physics for in our games are for adding gravity, collision detection, a character controller, keeping objects from falling through level/terrain geometry, physical interactions with world objects, triggers, vehicles, and ai, all of which should be able to be solved in a generic manner with a simple to use series of well written classes using NxOgre.
After a few weeks of work, a lot of reading, and asking a number of questions in the forums, I've only been able to get some working actors and bodies setup, with gravity and a plane as a floor, and the ability to apply forces. I've been so wrapped up trying to find small undocumented solutions, that I haven't been able to implement a full class yet to solve even one of the aforementioned problems. However, I ask myself...why am I spending weeks implementing something that thousands of others have probably done before me, and which they have probably done it a whole lot better. I also know that when I finish with the implementation, I'm going to have move on and also spend weeks implementing something else that someone else has probably already implemented, and quite possibly better, as they've had time to test it and optimize it.
So here is my proposition: If you've figured out how to do anything major with NxOgre, and implemented a stable and working class, library, set of classes, major functions, etc., that does anything useful that others might want to use with NxOgre, and which would take time for someone else to implement, please share the full source code here! If everyone that has solved a major problem posts their full solutions here, we can figure out who has the best solutions, then all use those in our games/applications. The whole theory behind the licensing of this stuff anyway is that everyone shares, and we work together to make it better! Instead of spending time reinventing the wheel over and over again, we need to work together on making the best classes built with NxOgre better, making them more robust, efficent, and stable. This then helps all of us achieve our goals. If the same piece of code is used and tested by hundreds of programmers, it is far less likely to have problems when you go to release your applications, and also should execute at top speed, as input can be taken from the group as a whole on optimizations. Additionally, this would cut down on the number of questions posted to the forums, and consequently, the number of questions betajaen has to answer -- which in turn will free up a significant amount of time for him to continue his work on NxOgre itself, and also give him optimized classes to use for testing his work, so he doesn't also have to create these.
There are also many things that aren't yet implemented in most versions of NxOgre which others have already solved and added to their games/applications, such as characters, fluids, cloths, physical particles, etc. If you've solved any of these problems, please don't horde your solution! Share it with the community!
I've created two seperate threads for this, one for bleeding, and one for bloody mess, depending upon the version you're using. Please make sure you post your code to the right topic. In the subject line of your posts, please post the version number of bleeding or bloody mess that you used to code your solution with, and what the solution solves.
If this works, and we all work together, this topic should be the most complete place available to quickly find a full solution to all your NxOgre/Physics needs. If you've built working classes/controllers with NxOgre, please post them, or post links to them here!! There are a number of wonderful and intelligent people here, let's work together to make NxOgre the best and only solution people consider for Physics when using Ogre!
Also, please note...when I refer to "here" in the above post, I mean the two forum topics [Bloody Mess] Important: Code Repository (Please Read!!) & [Bleeding] Important: Code Repository (Please Read!!), and not here in the Bloody Mess Development Blog.
Thanks!
spacegaier
25-04-2009 22:15:17
Karan
03-05-2009 22:25:38
What's the status on 1.5.4? A few weekends have passed since you first wanted to release it...