Flow Ogre Wrapper compatibility test

We decided to show something of flow since were getting closer to release. So heres one of the basic examples that come with flow that show you the basics of WASD character control, and boned anim control.

It's nothing fancy, but it will make for a good compatibility test. So let us know if it doesn't run.

The demo loads a OSM scene that contains a robot in two parts, and the rest is coded. Would have been simpler to just load the scene complete, but this does let you get a glimpse of using Ogre with Bmax.



You can DL the demo at:

http://www.flow3d.org/walkiestest.zip

NOTE: This isn't supposed to blow anyone away :), and the top half of the robot doesn't fit because most of the parts actually belongs to another robot.



Here's the main chunk of source code for the demo:

'Setting the Scene
	
	'Get the root scene node for attaching children-
		Global RootNode:TSceneNode = mainSceneManager.getRootSceneNode() 
	
	'Main scene light positioned to the right-
		Global Light:Tlight = mainSceneManager.createLight("mainLght") 
		Light.Setposition(- 40, 600, - 20) 
		Light.setDiffuseColour(1, 1, 1) 
		Light.setSpecularColour(.5, .5, .5) 
		Light.settype(TLight.LT_POINT) 
	
	'Load the Robot OSM Scene File-
		Local OfusionScene:TOSMScene = TOSMScene.Create(mainSceneManager, mainRenderWindow) 
		OfusionScene.initialise("walkie.OSM") 
		OfusionScene.createScene() 
	
		'Grab the robot legs entity and node-
		Global robot:TEntity = mainscenemanager.getEntity("Walkie") 
		Global robotnode:Tscenenode = robot.getParentSceneNode() 
		'Grab the robot head assembly ( head, weapons, mounts ) node-
		Global robotHeadAssembly:tscenenode = mainscenemanager.getentity("Box03").getParentSceneNode() 
	
		'Get the robot's spine for attaching the head assembly to-
		Global spine:TBone = robot.getSkeleton().getBoneWithName("MechPelvis") 
	
		'Get the robot leg's animations, enable standing by default-
		Global animWalk:TAnimationState = Robot.getAnimationState("Walk") 
		Global animStrafe:TAnimationState = Robot.getAnimationState("Strafe") 
		Global animStand:TAnimationState = Robot.getAnimationState("Idle") 
		animStand.setEnabled(True) 

		
	'Main Camera Setup
		Global cameraNode:TSceneNode = RobotNode.createChildSceneNode("cameraNode", 0, 0, 0) 
		cameraNode.setInheritOrientation(False) 
		Global mainCamera:TCamera = mainSceneManager.createCamera("mainCamera") 
		mainCamera.setPosition(0, 15, - 30) 
		mainCamera.setNearClipDistance(1.0) 
		'mainCamera.setAspectRatio(1.0) 
		cameraNode.attachObject(mainCamera) 
		
	'Set up the floor
		Global Floor:TEntity = MainSceneManager.createEntity("floor", "Plane01.mesh") 
		Global floornode:TSceneNode = RootNode.createChildSceneNode("floornode", 0, 0, 0) 
		floornode.attachObject(Floor) 
		floornode.scale(150, 0, 150) 
		Floor.setMaterialName("Rocks") 

'/Setting the Scene

'Viewport Setup
	Global mainViewport:TViewport = mainRenderWindow.addViewPort(mainCamera) 
	mainViewport.setBackgroundColour(TColourValue.Create(.5, .5, .5, 0.0)) 
	Global shadows:Int = True
	
'Variables used for mouselook-
	Global yaw:Float = 0
	Global mousepos_x:Int = ogre.width / 2
	Global mousepos_y:Int = ogre.height / 2
	Global currMouse_x:Int = ogre.width / 2
	Global currMouse_y:Int = ogre.height / 2
	Global mouserel_x:Int
	Global mouserel_y:Int
	Global rotyaw:Float = 0
	Global rotpitch:Float = 0
	
	cameraNode.rotate(0.0, 1.0, 0.0, 180, TS_LOCAL) 
	
'anim speed variables
	Global animSpeed:Float =.03
	Global strafeSpeed:Float =.5
	Global walkSpeed:Float = 1

Repeat
	mainCamera.lookAt(RobotNode.getPosition().x[0] , RobotNode.getPosition().y[0] , RobotNode.getPosition().z[0] ) 
	'Increase the animation timer each frame-
	'animState1.addTime(.005) 
	'Capture relative mouse coords-
	currMouse_x = MouseX() 
	currMouse_y = MouseY() 
	mouserel_x = currMouse_x - mousepos_x
	mouserel_y = currMouse_y - mousepos_y
	MoveMouse(mousepos_x, mousepos_y) 
	
	'Transform the camera based on these coords and keyboard activity-
	cameraNode.yaw(rotyaw + (mouserel_x * 3 *.025) , TS_LOCAL) 
	'cameraNode.pitch(rotpitch + (mouserel_y * 3 * -.025) , TS_LOCAL) 
	
	'Instead of actual movement, set up animations-
	
	'Check input to determine the states of the robot-
		animStand.setEnabled(False) 
		animStrafe.setEnabled(False)
		animWalk.setenabled(False) 
		
		'The following variables contain movement details:		
		Local Strafe:Int = KeyDown(KEY_D) - KeyDown(KEY_A) 
		Local Walk:Int = KeyDown(KEY_W) - KeyDown(KEY_S) 
		
		'Actually move the mesh:
		robotnode.translate(Strafe * strafeSpeed, 0, Walk * -walkSpeed, TS_LOCAL) 
		
		'Set the head assembly node's position to that of the spine bone. Get spine bone by transforming spine's local position
		'From it's parent bone by the leg entity's world transform.
		robotHeadAssembly.setPositionWithVector3(robot._getParentNodeFullTransform().mulWithVector3(spine._getDerivedPosition())) 

		'Lets reset animation type to keep animations synced together.
		If KeyHit(KEY_D) Or KeyHit(KEY_A) Or ..
		   KeyHit(KEY_W) Or KeyHit(KEY_S) Then animStrafe.setTimePosition(0) ;animWalk.setTimePosition(0) 
		
		If (Strafe Or Walk) Then
			If Strafe Then
				animStrafe.setenabled(True) 
				animStrafe.addTime(animSpeed * strafe) 
			End If
			
			If Walk Then
				animWalk.setenabled(True) 
				animWalk.addTime(animSpeed * walk) 
			End If
		Else
			animWalk.setEnabled(False) 
			animStrafe.setEnabled(False) 
			animStand.setenabled(True) 
			animStand.addTime(animSpeed *.1) 
		EndIf
		
		If KeyHit(KEY_C) Then shadows = 1 - shadows;mainviewport.setShadowsEnabled(shadows)
	'Render one frame every 60 seconds-
	ogre.renderOneFrame()
     Delay 1000 / 60	
Until KeyHit(KEY_ESCAPE) Or AppTerminate() 


End

Function Print(n:String) 
	
End Function

We will be releasing a modable game demo that shows flow being used in a game environment with integrated editor. Hopefully sometime in the second half of the month.



old vid we posted a couple of weeks ago, of a standalone version of the OSM editor in use.

http://www.flow3d.org/AD/speedup.wmv

It won't do my monitor's native resolution under DirectX, crashing with a Microsoft Visual C++ Runtime Library error (although it will do all the lower resolutions I have tested);

OpenGL won't do full screen at all, running windowed no matter what I select;

Under widescreen resolutions, the image looks stretched rather than the field of view being wider.

I've got an Intel '915GM/GMS,910GML' but none of those issues relate to the weaknesses of the card -- the actual rendering looks dandy. Looking forward to more :D

What's your monitors native resolution?

We have not coded anything to fit the aspect ratio- that would be up to the coder to support "widescreen". The functions to do so are included.

OpenGL isnt doing fullscreen? OK, something to look at. It is currently using a Max generated window (and using its OpenGL context-) which has been known to cause problems in the past. This was supposed to be fixed though.

Thanks for your response. We'll look into it right away.

[edit] OpenGL problem found, will provide Evak with an updated version ASAP.

[edit 2] Looks like its clashing with the Max generated OpenGL context, then creating its own window instead of sharing a Max window. This will require some time to fix. For now, OpenGL fullscreen will be ignored by the demo.

It works. You should make him keep his current frame of animation when he stops though, or settle into an appropriate position.

Ran fine on my system. Good work and the code sample looks simple enough, also.

:)

I never try to use OGRE under OpenGL it never seems to work ...

1280*800@32-bit

Sounds good. I only mention it as it's automatic under B3D and MiniB3D (and probably a few others).

I've had no problems with fullscreen OpenGL under the regular GLMax2DDriver, MiniB3D or Irrlicht. I just gave GLGraphicsDriver() a whirl too and it drops into fullscreen fine. EDIT: Oh I see you've found the problem in the interim!

It's a cool project -- just post if you need more info or code testing and I'll try to make time.

Ok, the widescreen is pretty easy really, theres one method of Tcamera I believe that just sets the aspect ratio.

I have no reason why it should fail to work in your native resolution. That is a bit odd. Anyone else having this issue?

SLedge, could you go into the Conf folder and look at the bottom of Log.txt? any error there? (there are usually tons of warnings, but there should be an actual exception at the bottom.)

In other news:

http://www.blitzbasic.com/Community/posts.php?topic=76350

There's no problem with OpenGL in max, but there has been a problem in the past where Ogre has not played friendly with the OpenGL context created by Max. This is the issue that was fixed. We can enter a fullscreen OpenGL window but it does not receive events, for this reason we are not going to update the demo with my fix just yet.

It turns out that Ogre is getting an invalid handle from GetActiveWindow() - which works in all circumstances bar openGL fullscreen, for some reason. We'll see what that thread turns up or if we need to do something our side to repair this. (like routing events to Ogres window- been on the cards for a while.)

The output is inconstitent. On OpenGL the ground etc is far brighter than in DX9.

Other than that and the mentioned window thing, no problem.

Core 2 Duo E6600, 8800GTS 640MB, 2GB RAM

Interesting. We also experienced this but it was down to an overscaled floor mesh being vertex lit- any chance of a screenie comparing the two? We diagnosed and fixed the problem before release so I'm shocked to hear you experienced it.

We will look into it.

Report

In OGL everything runs fine.

In DX9 I got the robot ok, bot the ground is just blank.

Yoko and Dreamora:- try redownloading? we *just* tweaked it a bit- the ground was still excesively scaled.

interesting, I just updated the ground. No one knew where the original plane mesh came from or even which version of ogre it was created for. It was being scaled up 150x150 times. I just updated a large plane with new UV's and no scaling.

Hoping that will have solved the strange ground problem for future downloaders.

You can update your version with the files in this zip if you want, or just download again.

http://www.flow3d.org/walkiegroundpatch.zip

137k It replaces the plane01.mesh, material, and exe. the original download link has been updated with the new files already.

Works fine here, OpenGL and DirectX.

Macbook Pro (running Vista) GeForce 8600M GT.

:)

Will test it when I'm back home.

Might actually relate to it as the mesh seems to be of the same brightness but thats always hard to say when the surounding world differs that much in brightness

Will test it when I'm back home.

Might actually relate to it as the mesh seems to be of the same brightness but thats always hard to say when the surounding world differs that much in brightness.

Looks nice, i like the shadows and that you can use building blocks with a grid but don't you get any vertices issues this way? What's missing is that after building the scene you can press the play-button in order to experience it. Is there a demo for osx too?

Report:

All Works now, btw my card is GeFX5200.

I would hope the OSX demo won't take too long but it won't be out at the same time as the Windows demo- We are still focusing on getting any bugs out of the windows release right now.

Thanks for testing guys.

Just tested on my office computer. It runs perfectly.
Ahtlon X2 4600, 2 Gb Ram, GeForce 6150 LE, WinXP Pro sp2

is your wrapper just a straight wrap of ogre commands, or does it have any simplification layers?

Why did you decide to go with ogre, over other libs?

Boomboom, Flow has two layers. In itself, it is as close to a 1:1 ogre wrap as we can achieve with Max. FlowGraphics is an easy-to-use layer (currently in development) that turns the Ogre functions closer to B3D.

We went with Ogre for Speed, Ease of use, Artist tools (Ofusion is nice!) and flexibility. It's a little beefier than other libs but it is capable of WAY more. Also, the cross platform aspect is nice too. (and Flow will be cross platform, It is a key feature.) The next version of Ogre will bring a few nice improvements and we'll be sure to bring Flow inline with it.

Ogre also has *tons* of libraries you can use with it. new render engine available? Shove it in the plugins directory.

I would like to play now! :)

Flow is more than just a wrapper, as well as Ogre, there's Newton Game Dynamics, CEGUI (skinnable, scriptable GUI with decent editors) plus you can use MaxGUI for native OS UI.

All chosen for being mature, cross platform and wrapped for direct control via blitzmam.

Plus theres FlowED OSM (Ofusion)scene editor for making things a lot easier without forcing you to use 3ds Max. The editor is integrated into the game demo and will let you load both meshes and scene files and save out again.

Quick glance at the C++ source and there are now just over 1700 functions wrapped across the various libs thus far.

Fullscreen is not working on OpenGL on my machine, I always get it windowed

Yeah, GL fullscreen is something we started looking at lastnight. In windows we used d3d almost exclusively and completely forgot about fullscreen not playing nice with the Bmax window. Thats at the top of our list for fixes now.

will it be free or will you charge?

Good call Evak, yes. there is of course more to Flow than just the Ogre wrap, we have also got the most commonly used libs wrapped too, and wrapped it in such a way as to copy the interface that you would use in C++, in Max.

Just thought I'd point out our C++ coder (registered here as....Olivia Nugglepuddins haha...) has really worked hard getting that side of the wrapper up to scratch, I'm quite pleased at where we are going even if it is a little slower than anticipated. *Praises*

Will this also be available for operating systems that are not coming from a certain corporation located in Redmond, Washington, United States?

Winni: Yes, this is one of the main features of this engine. The code we have used is portable, and wont take *too* long to get running in other environments. This work begins shortly.

Boomboom: there will be a fee (Three people working on it for 18 months, keeping it up to date, I feel the work is worth something!) but it will not be a huge ammount, we have not decided on the final figure though.

@Winni - yes it will be X platform - as mentioned above, but I don't blame you for not trawling through every post!

I think that's fine. Esp giving that it works with decent free engines. I have more faith in 3rd party stuff I have to pay for tbh.

Just if you do decide to stop supporting it in the long future (priorities change) please consider releasing the source

Here's the last portion of the log, the last three lines are interesting.

19:09:36: D3D9 : Subsystem Initialising
19:09:36: ***************************************
19:09:36: *** D3D9 : Subsystem Initialised OK ***
19:09:36: ***************************************
19:09:37: D3D9RenderSystem::createRenderWindow "mainWindow", 1280x800 fullscreen  miscParams: externalWindowHandle=394112 
19:09:37: D3D9 : Created D3D9 Rendering Window 'mainWindow' : 1280x780, 32bpp
19:09:37: OGRE EXCEPTION(3:RenderingAPIException): Failed to create Direct3D9 Device: Invalid call in D3D9RenderWindow::createD3DResources at ..\src\OgreD3D9RenderWindow.cpp (line 573)

What the heck!? It's trying to create a 1280x780 window?

That is indeed interesting.


OK! I just tried this myself too. INteresting, it is the blitzmax window being made at an odd resolution. Will look at it now, should be fixable. (This is likely a problem with the demo and not ogre.)

[edit]
Fixed. Zip updated.

Could you try redownloading and testing that for us?

:EDIT: This has been cleared up a few posts down, just ignore my paranoia, too much caffine and cake, its back on people! :EDIT:

Is the mystery C guy, 'Olivia Nugglepuddins', non-other than the notorious Antony? Being the guy who created a network lib (netoptica), and then 2 3D libs (VividGL, Aurora3D) for Blitz3D that were both immediatly dropped after people had bought them, and swore he would never work with Blitz again. Then in a burning rage of fury and immaturity, flamed the forums with abusive and threatening posts to the moderators, until he was banned?

Article 1: Notice the username of the video poster:
http://www.youtube.com/watch?v=zqitHZ38xO8

Article 2: A similer constructed username:
http://www.blitzbasic.com/Account/showuser.php?id=7294

Article 3: A connection to Ogre:
http://www.gamedev.net/community/forums/topic.asp?topic_id=392459

:EDIT: This has been cleared up a few posts down, just ignore my paranoia, too much caffine and cake, its back on people! :EDIT:

Tested on an Intel GMA 965 chipset.

Black screen in OpenGL (I expected this as nothing written in Blitzmax works in Vista using OpenGL).

Works ok in DX9 window although the shadows slow it down massively.

DX9 fullscreen, it returns to desktop with no error.

<heavily edited>
It looks like it.

To be fair, I didn't use 'Olivia Nugglepuddins' in any of my searches, so Cygnus can't be blaimed. It was actually the youtube video that started the breadcrumbs.

I also found a post on the ogre forums that Antony posted that mentions evak

I wouldn't blame anyone for feelign that way, but I wouldn't think twice personally. If it hadn't been Antony ( assuming it even is, and frankly, I just assumed all along it would be ) it would have been someone I didn't know at all, so I really wouldn't have had any trust in a stranger anyway. I would have been putting my trust in the people standing behind the project, which is Evak and Cygnus. Who they choose to use as freelance talent is up to them, and I don't think anyone has any doubts about Antony's skills as a programmer anyway.

Now that said, I already have a mature 3d engine, and I'm not seriously considering Flow ( except maybe to play around with, I do own a few 3d engines just for larks ) so I can't say for certain I wouldn't feel differently if I wanted to actually develop something with it. But Evak and Cygnus both have a good name around here, so I don't think it would affect me.

If there hadn't been any extra posts I would edit mine (in fact I still will). Nothing to say it is Antony (in fact this states strongly it is not) so wouldn't want to put the scuppers on anything due to hearsay.

@Gabriel, I agree that Antony is a talented programmer when it comes to snippets but his projects and support are generally awful. Maptrix anyone?

Nice find tonyg...very intresting, hopefully someone can clear this up.

Oh my... wow...

Guys, I can promise you this, we are *NOT!!!* working with Antony.

As you saw in the previous link,Lina is our coder (she registered here under the beforementioned name) and she is incredibly tallented.

Boomboom: I'll admit this, we have worked with Antony in the past. We decided back then that his tallents were worth another shot but he was pretty much impossible to work with and did things like make releases without permission, and *GIVING AWAY* source code to a game that was not part of Aurora. After a couple of months of work he released Aurora *without* our permission and shortly after that we stopped working altogether.

Evak and I were determined we could help the community (and ourselves)and went in search of a replacement. In the meantime for our projects we used Sow (and helped Chris with feature requests) until Chris recieved a ton of unfriendly emails while he was on holiday from people on this forum. He was ultimately disheartened by the behavior of those few.

So then we were again back at stage one- At this point we had two options- pack it in, and get on with our lives, or give it one last shot and give it all we had.

I knew Lina before we started working together and managed to get her on our team. We have worked our arses off since then, on a project now known as Flow. THAT is what this project is.

Again, It is *not* linked to Antony in any way whatsoever. I cannot make that point strong enough.

Myself and Evak have been working together for quite a few years- I would like to think that neither of us have done anything to cause distrust here.

Thats good enough for me, I have always like yours and evak's work, thanks for clearing this up, and I guess out of anyone, you two were stung the most. Hes a great coder (probably one of the best thats ever graced these forums), but just sucked at the aftersales and business side of things.

And I can understand why Lina likes to keep hidden, girls quite often are somewhat 'harrased' on programming forums.

Infact its a good tip, if you ever want to get more attention and help, is to pretend to be a girl coder...

:) Edited my original post

No problem. It's amazing how 2 months can give you a headache for the rest of your life.

Anyway guys, can we get back on topic- this is a testing thread. We need you guys to test the hell out of this!
Anyone who gets a crash, can you check the LOG.TXT file in the CONF folder?

GfK, could you do that for us too, let us know the last few lines of LOG.TXT

Thanks

lol, Unfortunately the three initials for my real name spell out ANT, which I've been called longer that the infamous blitz Anthony has been alive. Just to clear that up, Antmax and Adriantmax are both my older pre blitz nicks. Stands for Adrian + 3ds Max.

Lina is a great C++ coder, doesn't like posting forums or drawing attention to herself. Not even sure she has ever posted on here. I didn't even know her nic till Cygnus mentioned it above lol.

Shader Example works only in DX9 here. Opengl shows only a white floor. Example without shaders works in DirectX and Opengl.

This looks great, can't wait for it to be released, anyway:

Shaderf Skeletal Animation Demo using OSM.exe

The ground is all white on my version when using OpenGL, run fine in DirectX, but OpenGL doesn't

Skeletal Animation Demo using OSM.exe runs fine in both version.

yeah, its a HLSL offset bumpmap shader I threw together with the 3dsmax exporter in a couple of minutes lastnight before I went to bed. I'll set it to CG and see if the HLSL code still works.

Sometimes HLSL shaders just work as CG shaders when you set a couple of parameters, didn't work in this case unfortunately.

I updated the zip so there's a single EXE and you can press R to see the offset normal mapped ground in D3D mode (if your GPU supports PS2.0

Shaders are a bit of a pain since all the tools support HLSL and D3D only.

Just checked it out on my Intel GMA900 tablet:

1. the 2nd version (after the ground fix) of the DX one worked and looked more correct
2. The new versions are totally broken. The shaderf has super high texture repetition. I as well can only move left right, not forward backward (the robot animates correctly but the ground does not react to it visually)
The regular one just crashes with a runtime error (VC++ Runtime Library - abnormal program termination)
Funny enough, in opengl both ran without crashing, the shaderf had a blank ground, the other one worked without problems ... seems like one of the links to DX is broken or the like (VC++ 7, 2005 2008 runtime redists installed)

GMA 900 has PS 2.0 but no Hardware Vertex Processing if that helps.
But I was really stunned to see that the ground fixed version worked with the dynamic shadow even when it didn't perform really well (10-15fps I would guess)

So whatever you fixed, something got dfixed.b

As odd as that is, perhaps the problem with forward/backwards is that it just happens to be moving a the same speed as the texture repetition?

There seems to be a few integrated problems popping up. Any chance of a screenie of that repetition?

Could it be the lack of hardware vertex processing causing the shader version to break.

I tested the latest demo in my wifes work laptop(has been very problematic). Radeon Mobility X300. It's very slow with shadows in 32 bit, 2x as fast in 16 bit. And the shader works and doesn't have much impact on performance. the X300 does have a single vertex unit onboard though.

The shaders should look like this.

here is a screen of the error



as mentioned, it worked in the original version

funny enough the new ogl fixed version works totally including the bump mapping (only for ogl, in dx the exe still crashes with the runtime error)