0.4 RC2 - The NxOgre library will be released today!

betajaen

13-10-2006 19:16:45

The development diary of NxOgre 0.4 RC2

betajaen

14-10-2006 19:43:59

Day 1

Apart from the usual stuff, I have some ideas of new things in NxOgre:

- A type of body that is a static geometry which accepts many types of shapes and entities. Once "built" a static geometry and a collision model is built at the same time. Very useful for level bits.

I'm going to hold small competition here, Theperson who decides on a good name for this class (Not StaticGeometryBody) , I will immortalise them in the NxOgre code.

- Body instancing. I've seen a few clever people on the main forums doing this sort of thing. It would be a single class with main instances, which share a scene node. Good for non gameplay physics.

[Edit]

Oh, I forgot destructible bodies too.

betajaen

19-10-2006 19:34:51

Day 6
This feature will be released as part of RC1 Ultimate Edition in the next week or so.

Prefab system

The prefab system has now been completely destroyed, I'm sad to say. It's had a good run but it's being replaced by the controllable class.

But don't worry your favourite prefabs will be back in a better form. Rumor has it the vehicle prefab has been replaced with a namespace with 5 separate classes inside. But you didn't here that from me.

Levitator

The "levitator" is a funny named class which does exactly what it says on the tin, hovers x metres off the ground. Very useful for flying DeLorean's.

Shown in this movie:

wspnut

19-10-2006 20:00:44

Flexible Entity + Static Geometry + Built in Collision Model - (StaticGeometryBody)


::the computer is thinking, please wait::


DING! Brownies done!


How about "CompositeBody" :)

ColeZero

19-10-2006 20:05:42

Thats nice, really cool..

Gauntlet

20-10-2006 09:56:17

Awesome, I really can use this Levitator class!

betajaen

23-10-2006 15:33:19

Day 10 - Stages
This feature will be released as part of RC1 Ultimate Edition in the next week or so.

No screen shots this time, I can't really take screen shot of things which are invisible.

Stages for the people haven't heard of the concept before, are my own invention of splitting up the scene and applying specific properties to them. Pretty much like a state trigger, but with a twist.

There is always an "active" stage, this is where the action is, other stages should then automatically reduce the level of detail depending on the type of stage and distance from the active one. This could be as simple as hiding the scenenodes, to freezing the bodies or even saving the contents to a blueprint and deleting the originals. All in aid to speed up the simulation.

It's secondary purpose, briefly described above stages split the scene up. A good example would be a space ship, each compartment of the ship is a stage, applying gravity. Even outside the space ship is a stage as well. Obviously the space stage has no gravity, so anything from the ship stages would no longer listen to gravity either, it has no atmosphere so any body on fire would be put out too.

There can be many other uses for stages too, in an FPS for example. A windy street could be one stage, and the buildings would be separate others where wind be not there.


As for the implementation, the class is implemented and it passes on the states and removes them when needed. I need to set up the code to handle active, and write a few tutorials for it too.

Ridhan

23-10-2006 15:47:13

Sounds freaking awesome :D !!!

Keep up the good work :!:

betajaen

24-10-2006 11:48:18

Day 11
This feature will be released as part of RC1 Ultimate Edition in the next week or so.

As reported in the Flintstone thread, I have debug working.

To celebrate it, I NxOgre'ised the leak report given out by PhysX:


11:43:40.000001 Starting up NxOgre using versions:
- PhysX SDK 2.5.1
- Hardware Yes, Athena 1.0
- NxOgre NxOgre 0.4.RC2 (Compatible: yes)
- Ogre 1.3.0 'Eihort'
11:43:40.000001 Started.
11:43:40.000001 Creating scene 'Main'.
11:43:43.000159 Shutting down.
11:43:43.000159 Scene 'Main' (Software) shutting down
> 35 bodies
> 35 NxActors
> 0 controllables
> 0 fluids
11:43:43.000159 Deleting 'Main.floor'.
11:43:43.000159 Deleting 'set'.
11:43:43.000159 Deleting 'cube0'.
11:43:43.000159 Deleting 'cube1'.
11:43:43.000159 Deleting 'cube2'.
11:43:43.000159 Deleting 'cube3'.
11:43:43.000159 Deleting 'cube4'.
11:43:43.000159 Deleting 'cube5'.
11:43:43.000159 Deleting 'cube6'.
11:43:43.000159 Deleting 'cube7'.
11:43:43.000159 Deleting 'cube8'.
11:43:43.000159 Deleting 'cube9'.
11:43:43.000159 Deleting 'cube10'.
11:43:43.000159 Deleting 'cube11'.
11:43:43.000159 Deleting 'cube12'.
11:43:43.000159 Deleting 'cube13'.
11:43:43.000159 Deleting 'cube14'.
11:43:43.000159 Deleting 'cube15'.
11:43:43.000159 Deleting 'cube16'.
11:43:43.000159 Deleting 'cube17'.
11:43:43.000159 Deleting 'cube18'.
11:43:43.000159 Deleting 'cube19'.
11:43:43.000159 Deleting 'cube20'.
11:43:43.000159 Deleting 'cube21'.
11:43:43.000159 Deleting 'cube22'.
11:43:43.000159 Deleting 'cube23'.
11:43:43.000159 Deleting 'cube24'.
11:43:43.000159 Deleting 'cube25'.
11:43:43.000159 Deleting 'cube26'.
11:43:43.000159 Deleting 'cube27'.
11:43:43.000159 Deleting 'cube28'.
11:43:43.000159 Deleting 'cube29'.
11:43:43.000159 Deleting 'cube30'.
11:43:43.000159 Deleting 'cube31'.
11:43:43.000159 Deleting 'myCamera'.
11:43:43.000159 Deleted Materials
11:43:43.000159 Deleted Material aliases.
11:43:43.000159 Released Scene.
11:43:43.000159 Calculated physics for 1.503 seconds.
11:43:43.000159 Goodbye.
11:43:43.000159 User Allocator Stats

- Total alloc: 1197
- Number of realloc: 2
- High water mark: 863 Kb

Leaks detected (165188) bytes
- Remaing allocs: 7

(0) -> Address : 03602C08
Bytes : 4097 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
(1) -> Address : 03603C50
Bytes : 8196 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
(2) -> Address : 03605C98
Bytes : 12294 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
(3) -> Address : 03608CE8
Bytes : 16392 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
(4) -> Address : 0360CD38
Bytes : 20490 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
(5) -> Address : 03611D88
Bytes : 28019 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
(6) -> Address : 03618B40
Bytes : 75700 (maxSize)
File : z:\nxogre\nxogre\src\nxogre_util_stream.cpp : 196
- Leak dump complete (7)


Don't worry, that isn't normal. I'm NOT deleting something on purpose.

[Edit]

And as for a full Ogre leak report, I'm happy to say:


----------------------------------------------------------------------------------------------------------------------------------
| Memory leak report for: 10/24/2006 11:51:02 |
----------------------------------------------------------------------------------------------------------------------------------


5 memory leaks found:

Alloc. Addr Size Addr Size BreakOn BreakOn
Number Reported Reported Actual Actual Unused Method Dealloc Realloc Allocated by
------ ---------- ---------- ---------- ---------- ---------- -------- ------- ------- ---------------------------------------------------
004938 0x0132C5C8 0x00000088 0x0132C5B8 0x000000A8 0x00000000 new N N ??(0) ??
004935 0x032DE1E0 0x0000002C 0x032DE1D0 0x0000004C 0x00000000 new N N ??(0) ??
004952 0x032E86C8 0x0000007C 0x032E86B8 0x0000009C 0x00000000 new N N 102.cpp(91) NxTutorial::start
005050 0x032E9A58 0x00000084 0x032E9A48 0x000000A4 0x00000000 new N N 102.cpp(102) NxTutorial::start
005148 0x0330F1E0 0x00000090 0x0330F1D0 0x000000B0 0x00000000 new N N tutorialapplicationeihort.h(683) SimpleTutorialEihort::ApplicationStart


That the only two leaks that NxOgre makes, is it's NOT deleting the shapes (new cubeShape) when a body is destroyed. Indicated on the 102.cpp lines.

I belive the first two leaks are normal DirectX and Windows. The tutorialapplicationeihort.h leak is I'm not deleting the NxOgre raycaster used for mouse picking in the tutorials, it should be deleted in NxOgre anyway but I don't think the Scene keeps a copy of the pointer.

Not bad indeed.

ColeZero

24-10-2006 13:21:31

Great thats awesome, man..
How long I've been waiting for this..
Debug-Mode, wohooo, thats great..
I won't have much sleep, until you release this...

CaseyB

24-10-2006 13:33:13

betajaen you ROCK! THis is awesome!

betajaen

24-10-2006 16:52:15

Thanks guys.

I have found memory leaks with the meshShape though, when it generates the mesh. I wonder if it generates any if I just load it from a .col file. I shall investigate.


Also it seems, this RC1 Ultimate Edition is going to be a waste of time, how about I release RC2 within a week instead?

Wretched_Wyx

24-10-2006 17:31:56

Oh my, that new debug / leak report is nice. I really like the idea of stages. I can see a big performance boost when utilizing this. Which is obvious of course :wink:. Keep up the great work.

[EDIT]
RC2, as opposed to RC1UE- sounds quite logical to me. You've added a good amount of new features, and squashed some bugs. Seems worthy of an RC2 title :).

Ridhan

24-10-2006 17:50:13

I agree. This is a RC2 definitely :D

betajaen

24-10-2006 18:08:20

Alright, It's official RC2 aka "Thor" will be out within a week or so.

betajaen

25-10-2006 16:48:45

Day 12

Mesh Cooking
Alright, meshShapes can now be saved to disk in it's own file format "nxs" or I assume by the file header NxShape.

It's really easy:
new meshShape("myMesh.mesh", myScene, param<mesh>("save:yes"));

Then to use it again:
new meshShape("myMesh.nxs");


Nice and simple. Since the nxs mesh is pre-cooked, it's much faster to load in, also if you wish you can force the mesh to be cooked to disk or memory.

params<>

Second part is the params<> class, which to be honest is in RC1 but nothing makes any use out of it. Basically it's to provide extra parameters to the mesh, or the joints or anything that can take many different variations of things but it's stupid to put into arguments of a constructor or a function.

In Ruby we can do lovely things like this:

meshParams :save => yes, :cook => :disk

Well in NxOgre you have something ever so similar:

params<mesh>("save:yes, cook:disk")

Not to shabby. :D

CaseyB

25-10-2006 17:04:41

That's awesome! There have been a lot of times when I wanted to create a constructor with a lot of args, but if someone wanted to change a default from the end of the args list they would have a lot of typing to do and it would look ugly! This allows people to change only 1 or 2 of the defaults in a very nice, clean way! Good work!

CaseyB

25-10-2006 17:35:37

The param stuff is very cool! I wonder if it's something they would be interested in rolling into Ogre proper?

betajaen

25-10-2006 18:09:18

Well they have that typedef'ed std::map<Ogre::String, Ogre::String> don't they?

CaseyB

25-10-2006 18:11:13

Right, but they don't use it like you do! I've only seen it used when passing params into an Ogre::MovableObjectFactory.

betajaen

25-10-2006 18:16:15

Gangsta uses it too for pretty much anything.

I have an idea, which is quite, quite cunning for only one small let down, which I will come to in a minute.

First we have a innocent data holder class:

class value {

/// Lots over overrides to accept integers,bools, strings, vectors,etc.

};


And some parameter types


enum paramTypes {
SIZE,
WIDTH,
SAVE,
FILENAME
};


Then a parameter dictionary:


typedef std::map<paramTypes, value> params;



Now can we do this in C++?

params p = {
FILENAME = "c:/cooked.mesh",
WIDTH = 15.24f,
MAKECOPY = true
};


Because if we can, I will dance like a crazy mad man.


Edit

I may be able to pull it of with an array and a macro, I shall keep you as always informed.

betajaen

25-10-2006 23:21:35

Alright, this is much much harder than I though it was.

The closest I have got to is the following:



param x;

x << P("Hi","There")
<< P("And","This");



It's not to bad, but I think it can be better.

betajaen

25-10-2006 23:39:05

And it is!

Get your head around this:


makeCake(
param("Slices","6") <<
param("Icing","Chocolate") <<
param("Candles", "Yes")
);


Obviously, I'll add support for non-string type values but I think we are onto a winner here!

[Edit]

Since, I'm a nice person here is the code:

struct param {

param() {}
param(string a, string b) { k=a;v=b; }
param& operator<<(const param &p) {
gp[p.k] = p.v;

if (k!="")
if (gp.find(k) == gp.end())
gp[k] = v;

return *this;
}

std::string k, v;
std::map<string,string> gp;

};

ColeZero

25-10-2006 23:42:39

The word "awesome" needs a new definition.......
Awesome: A guy in a forum named betajean, who is the developer of nxOgre.

What else to say?

Simply Great..of course all the other developer around ogre are great, too ;)

betajaen

25-10-2006 23:48:40

*Takes a bow*

I do amazing work around's when I'm really can't do something in a programming language.

It also helps when you watch Torchwood on BBC2 for two hours wrestling over a solution in your head. :D

betajaen

27-10-2006 19:21:38

Day 14

NxBetajaen



That my friends is one part of a program named after myself "NxBetajaen", it's a small pre-compiled program which does the following:

  1. Before compiling it checks to see the environmental variables have been set.
    1. Yes Comments on the nice tie you are wearing and let's it compile.[/*:m]
    2. No Produces the above dialog and automatically figures out where the libraries are. Ideally you should only need to put in the Ogre Directory, because NxBetajaen can find PhysX from the registry and NxOgre from the directory NxBetajaen is in.[/*:m][/list:u][/*:m]
    3. After compiling it copies all of the required DLL's over for you to the tutorials folder after a successful compile.[/*:m][/list:u]

      It may be a bit over the top here, and some say might be intruding on your computer, but for newbies it's a good thing. In another sense it's like me sitting next to your computer and setting everything up for you, hence the name ;)

      And for you veterans out there, you'll never see it as you'll have the environmental variables already set :wink:


      Splitting up the tutorials

      The tutorials now are split up again, and will be in a separate download from the core library. I feel it's better for some of the hardcore users around here who just want the library and the documentation can wait later, perhaps even more when most of the archive is media.

      The bloat monster

      I've make a difficult decision that I'm removing the prefabs from the NxOgre library, the classes will be moved over to the related tutorials as controllables; So the levitator class will be in the levitiator tutorial, vehicles in the vehicle tutorials,etc.

      The character controller will stay, as there is a specific DLL for it in PhysX/

      The difference is the NxOgre library is just deals core physics now, anything fancy is dealt in the tutorials and the implementation is freely available to ever wants it. Very little strings attached. To be honest;NxOgre was becoming a framework.

      Besides I will be doing an "expansion pack DLL" later in the year with all these things in, and more.

      You may blame 37 Signals for this one.


      Edit....

      Oh I forgot, I'll be adding params to the major classes now. So expect to pass on scale, overriding scene nodes, offsets, replacement materials directly into the constructors not to soon. :wink:

DaCracker

27-10-2006 21:41:18

This looks awsome!
I'm looking forward to play with it :D

Wretched_Wyx

28-10-2006 00:22:23

Why do I get a feeling that nice little guy will someday turn into a beast of a utility? Anyhow, that's a fantastic idea and should prove ever so useful. In the words of a drunken hobo in this bar I was in once, keep 'em coming.

betajaen

28-10-2006 10:43:58

Hobo bars? I think you need some new friends.

ColeZero

28-10-2006 16:57:01

Thats looks kewl, but i don't think that i going to see this screen, because my variables are always double-checked..^^
But anyway, that tool is great..