[Bleeding] 1.0'22T4 (Unstable) for download. Testers needed.

betajaen

08-10-2008 22:03:41

WHAT? Betajaen you insane!!

This is literally hot of the presses. This NxOgre 1.0'22 of course; I've worked with this code for under 24 hours, so I declare it unstable.

However; not to confuse the newbies I won't be placing it on the SVN straight away, until I am satisfied that it actually works with the masses - due to the changes of the core parts.

If you have been using NxOgre for less than two weeks, and even attempt to download this file - I WILL LAUGH AT YOU.

Release Notes

1.0 '22T4

    ~ GroupIdentifier is now a NxEither class.

    ~ Added several functions to shape, to allow changes to the shape before and after

      the shape has been created; localPose, Skeleton, material, group, skinWidth and flags. 

    ~ Added size to Betajaen::SharedListIterator 

    + Added MaterialAlias class

    ~ Added createMaterialAliasFromMaterials function in Scene

    ~ Added MaterialAlias loading/saving callbacks in ResourceCallback

    + Fixed a minor bug when loading in a skeleton the type of mesh was still "unknown".

     

<Betajaen: 08-October-2008>

Download

http://get.nxogre.org/releases/NxOgre.1.0.22T4.zip (400kb)

All problems, compile errors and thumbs up in this thread only.
If I see any posts outside this thread - I WILL DELETE THEM.

betajaen

08-10-2008 22:13:32

Okay, after ~14 hours of programming. I'm going to take a break.

spacegaier

09-10-2008 20:28:26

Hi betajaen,

I've just switched to T4, but now I'm getting a runtime error

. It only appears in release mode.

It happens here (it's part of my tries to get CCD running, which does not work either, but I'll post on this in the appropriate thread):

NxOgre::Actor *body = m_Devices.m_pNxScene->createBody<Body>("cube.mesh", new Cube(scale * physics_scale, "skeleton: mySkeleton, shape-flags: +ccd"), pos, nrp, "mass: 10");

My IDE then jumps to these lines of your code:

NodeRenderable* OgreSceneRenderer::createNodeRenderable(NodeRenderableParams params) {

	OgreNodeRenderable* renderable = NxNew(OgreNodeRenderable)(params, this);

	return renderable;

}

Here the german error text:
Windows hat einen Haltepunkt in NxOgre BleedingPlayground.exe ausgelÃ¶st.

Dies kann auf eine BeschÃ¤digung des Heaps zurÃ¼ckzufÃ¼hren sein und weist auf ein Problem in NxOgre BleedingPlayground.exe oder in einer der geladenen DLLs hin.

Weitere Analyseinformationen finden Sie mÃ¶glicherweise im Ausgabefenster.
In english:
Windows has caused a breakpoint in NxOgre BleedingPlayground (which is my app name).

This could be caused by a heap violation and prompts for a problem in NxOge BleedingPlayground or in one of the loaded DLLs.

Additional information can probably be found in the ouput window.
Any ideas concerning the problem?

EDIT: This is written in the output window. Perhaps it helps:
HEAP[NxOgre BleedingPlayground.exe]: Invalid Address specified to RtlFreeHeap( 003F0000, 0012F7B0 )

betajaen

09-10-2008 20:34:38

Hmm, Seems to be related to the NodeRenderable.

What happens with this?

NxOgre::Actor *body = m_Devices.m_pNxScene->createBody<Body>("CubeTest1;cube.mesh", new Cube(scale * physics_scale, "skeleton: mySkeleton, shape-flags: +ccd"), pos, "mass: 10");

spacegaier

09-10-2008 20:39:03

Now it does not crash anymore. Seems to work. Thanks.

spacegaier

09-10-2008 20:56:05

But now, the visual size of the body shapes does not fit anymore.

Before the version switch, the visually seeable size was also the size of the PhsyX collision shape. But now I see huge (perhaps 50 times huger cubes), but the size of the collisions shapes has not changed, according to the remote debugger.

betajaen

09-10-2008 21:02:59

You can scale the node by hand via the NodeRenderable.

But I'll have a look tomorrow to see if there is any problems with the alternate Actor constructor.

spacegaier

09-10-2008 21:16:01

Is it the right way to first crate a normal OgreSceneNode and attach an OgreEntity to it. Then create an instance of the NodeRenderableParams which is than given to the createBody() function (this is basically the code from the wiki tutorial).

My box creation code looks now like this:

static const Real mesh_scale = 0.02;

static const Real physics_scale = 2.0;

String name = "Box_" + StringConverter::toString(createdObjects);

createdObjects++;



//	[OGRE] create box, set material and scale it

Ogre::Entity *E = m_Devices.m_pSceneMgr->createEntity(name+"_entity", "cube.mesh");

E->setMaterialName("Examples/10PointBlock");

Ogre::SceneNode *sn = m_Devices.m_pSceneMgr->getRootSceneNode()->createChildSceneNode(name+"_node");

sn->attachObject(E);

sn->setPosition(pos.x, pos.y, pos.z);

sn->scale(Vector3::UNIT_SCALE * mesh_scale * scale);



//	create node renderable parms for body

NxOgre::NodeRenderableParams nrp;

nrp.setToDefault();

	

nrp.mIdentifierUsage = NxOgre::NodeRenderableParams::IU_Use;

nrp.mIdentifier = sn->getName();



NxOgre::Actor *body = m_Devices.m_pNxScene->createBody<Body>("CubeMesh01;cube.mesh", new Cube(scale * physics_scale, "skeleton: mySkeleton, shape-flags: +ccd"), pos, "mass: 10");

body->addForce(Vector3(0,0,-100), NX_IMPULSE);

AND: I'd really like to see a way in NxOgre (if not already implemented) to order NxOgre to automatically scale the PhsyX shape to the size of the given OgreEntity. Would make the whole thing a lot more easy.

mcaden

10-10-2008 03:27:51

I think a release system like this is much more beneficial.

Have a stable release available for download, and have unstable in SVN. Then if somebody NEEDS one of those cutting edge features they can use SVN to access a specific release of unstable, and the normal user can simply download the latest stable.

So unstable should be something like simply revision 26 and 1.0'21 should actually be [Stable] version 1.0 - when there's enough features to justify a new release you just turn whatever revision that is into [Stable] 1.1 and keep going with revisions on unstable with new and experimental features.

Prophet

10-10-2008 07:30:17

Yes, pretty much like the Ogre SVN. I think so too.

betajaen

10-10-2008 09:06:47

I'm going to start doing that, I would say next Wednesday would be the first stable; NxOgre 1.0.23

I bought virtual hosting last month, and I've been slowly moving my domains over. However since I more or less "own" the server, I have to install apache/php by hand - which has hesitated me to move the nxogre.org domain over including the SVN repository.

Git seems to be the rage these days as well, would there be any objections if I moved over to that?

spacegaier

10-10-2008 15:15:11

Well, objections...not really, but I'm not the kind of person who wants to install hundreds of small programs on my pc

But if there are many great advantages of GIT in comparison to SVN, moving would be okay.

betajaen

10-10-2008 15:51:58

Git is just for nightlies, everything else would be as a zip file or an installer.

I had the idea of redesigning the release system around the subdomains of NxOgre. So it would go:

get.nxogre.org - Most stablest, most important release, as MSI.
stable.nxogre.org - Latest stable releases of Nightlies or subpoint releases as zip files, these files are more than a week old and no reported problems. But aren't considered important enough to be on the front page.
unstable.nxogre.org - Nightlies that are more than 48 hours old as zip files.
edge.nxogre.org - Bleeding edge code, as pure source code.
tools.nxogre.org - Flour, the exporters created by the zombies and so on.

Prophet

11-10-2008 09:15:43

I see no reason why to move over to GIT; most of those who are interested in the bleeding-versions are probably using Ogres SVN, thus not wanting to install yet another software.
That is, unless it has some vital, very important features which would evolve NxOgre to a higher beeing and be worshipped until the end of time.

betajaen

11-10-2008 09:35:20

I don't mind either really; It's just GIT seems to be now hip thing these days in programming.

mcaden

11-10-2008 16:30:22

I don't mind either really; It's just GIT seems to be now hip thing these days in programming.

Never heard of it

betajaen

11-10-2008 16:40:30

On a different note; I've been rewriting the Contact Callback system from scratch, adding the ability for ActorToActor callbacks rather than the generic ActorGroupToActorGroup callback.

It's theoretically faster because there are no conditional checking that gets in the way and the template system has been removed - but the user can still supply their own functions and classes. Get your brain around that. Oh; and you can create a callback for just one actor.

Prophet

11-10-2008 17:06:15

Thanks, been waiting for that.
Is it still possible to use the ActorGroupToActorGroup? One thing that would be nice to see would be contact callbacks between body-types.

mcaden

11-10-2008 17:08:33

the template system has been removed - but the user can still supply their own functions and classes.

You mean the body templating? You removed it, or you implemented the custom body system in a different fashion?

If you removed it I'll stick to '22T2 which I'm currently using and remove my DotSceneLoader. If you changed to a different method of custom bodies I'll need to revamp the DotSceneLoader I just posted. If I'm misunderstanding it to mean some sort of templating dealing with the collision system I'll be relieved.

Elaborate please?

betajaen

11-10-2008 17:26:26

Bah, I was going to save this 4000th post for something special.

What I mean is, that the current template system is removed for something better. You can still have your functions named "SweetyMonkeyArmpits", it's just implemented differently.

mcaden

11-10-2008 17:39:47

K, I'll edit my DotSceneLoader code when you release it.

betajaen

11-10-2008 18:25:41

It's really easy to implement a callback now. It goes.

class Harry : public ActorContactCallback

{

 public:

   Harry();

   ~Harry();

   void SomeoneTouchedHarry(Actor*,Actor*, NxContactStream&);

   void SomeoneIsStillTouchingHarry(Actor*,Actor*, NxContactStream&);

   void SomeoneStoppedTouchingHarry(Actor*,Actor*, NxContactStream&);

};

Harry::Harry()

{

  mContactFunctions[_onBeginContact] = _ActorContactCallbackFunction(&Harry::SomeoneTouchedHarry);

  mContactFunctions[_onEndContact = _ActorContactCallbackFunction(&Harry::SomeoneStoppedTouchingHarry);

  mContactFunctions[_onContact] = _ActorContactCallbackFunction(&Harry::SomeoneIsStillTouchingHarry);

};

It's much faster than conditions when you can just use an array of function pointers that each position is an enum value.

Prophet

12-10-2008 12:20:48

Congratulations on the 4000th post.
But who exactly is Harry? Do you just inherit ActorContactCallback to the kind of body/actor you want to create custom callbacks for?

betajaen

12-10-2008 13:22:40

Basically how it works now, is you can give NxOgre a list of contact callbacks (which every events is passed onto), otherwise if you want something more specific you can. Then you create your createContactPairs for each Actor/Actor combination you want.

I will be writing a new wiki article on this, and it's all new so bare with me.

mcaden

13-10-2008 15:43:14

I think even after I asked you to clarify I think I still misunderstood.

If I understand this correctly...

1) The templating system you are talking about removing/replacing is the one for callbacks and contactStream. Callbacks and contactStream now exist as an enum of function pointers

and

2) The new template system for our own Body types is still there and is NOT the template system you are referring to as being removed.

Is that correct?