Flow3D Compatibility update: GL issues fixed.

Ok, we spent all day fixing things. Felt a bit awkward starting a new thread. But this build will hopefully fix all the remaining problems.

Changes below:

Lina worked realy hard today and Flow is now set up to make its own window using a Fg (FlowGraphics) window rather than using a Bmax window. This makes it faster and easier to use with performance benefits. Now the rendering contexts won't fight and things should operate much more smoothly.


Fullscreen in GL now works properly.

Widescreen should work without stretching (needs testing on more machines)

The HLSL offset normal map shader was converted to CG and now works in both D3D and GL on PS2.0 Cards.

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







Here's the full source. I didn't post the ogre setup code for the original demo before,mostly because it was quite large and messy and detracted from the simplicity of the actual app code.

'Header
	SuperStrict
	Include "headers/flow_header.bmx"
'/Header
'Initializing Ogre
	AppTitle = "Flow [Escape to exit - C to toggle Shadows, R for offset normal map GL & D3D ]"
	fG.init(True) 
	HideMouse() 

'Setting the Scene
	
	'Main scene light positioned to the right-
		Global Light:TLight = fG.createLight("mainLight", Tlight.LT_POINT) 
		Light.Setposition(- 40, 600, - 20) 
		Light.setDiffuseColour(1, 1, 1) 
		Light.setSpecularColour(.5, .5, .5) 

	'Turn on shadows-
		fG._scene.setShadowTechnique(SHADOWTYPE_STENCIL_MODULATIVE) 
	
	'Load the Robot OSM-
		fG.LoadOSM("walkie.OSM") 
	
		'Grab the robot legs entity and node-
		Global robot:TEntity = fG._scene.getEntity("Walkie") 
		Global robotnode:Tscenenode = robot.getParentSceneNode() 
		'Grab the robot head assembly ( head, weapons, mounts ) node-
		Global robotHeadAssembly:tscenenode = fG._scene.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) 
		fG._camera.setPosition(0, 15, - 30) 
		cameraNode.attachObject(fG._camera) 
		
	'Set up the floor
		Global Floor:TEntity = fG._scene.createEntity("floor", "Plane01.mesh") 
		Global floornode:TSceneNode = fG._rootnode.createChildSceneNode("floornode", 0, 0, 0) 
		floornode.attachObject(Floor) 
		Floor.setMaterialName("Rocks") 

'/Setting the Scene

	
'Variables used for mouselook-
	Global yaw:Float = 0
	Global mousepos_x:Int = fg._ogre.width / 2
	Global mousepos_y:Int = fg._ogre.height / 2
	Global currMouse_x:Int = fg._ogre.width / 2
	Global currMouse_y:Int = fg._ogre.height / 2
	Global mouserel_x:Int
	Global mouserel_y:Int
	Global rotyaw:Float = 0
	Global rotpitch:Float = 0
	
	cameraNode.rotate(TVector3.Create(0, 1, 0), 180) 
	
	Global shadows:Int = True
	Global showRocks:Byte = True
	
	'Ad these are for you!
	Global animSpeed:Float =.03
	Global strafeSpeed:Float =.5
	Global walkSpeed:Float = 1

Repeat
	fG._camera.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 user hits "R" then toggle between offset materials and standard ( Direct3D Only! )
		If KeyHit(KEY_R) 
     		If showRocks = True Then
          		showRocks = False
          		Floor.setMaterialName("OffsetMappingSample") 
     		Else
           		showRocks = True
           		Floor.setMaterialName("Rocks") 
     		EndIf
		EndIf
		
		'If user hits "C" then toggle shadows
		If KeyHit(KEY_C) Then shadows = 1 - shadows;fG._viewport.setShadowsEnabled(shadows) 
	
		'Render one frame every 60 seconds-
		fG.renderWorld() 
     	Delay 1000 / 60
		
Until KeyHit(KEY_ESCAPE) Or AppTerminate() 

Here's what the old ogre setup code looked like:

'Header
	SuperStrict
	Include "headers/flow_header.bmx"
'/Header

' Initialize ogre-

'Initializing Ogre
	Global Ogre:Togre = Togre.CreateRoot("Conf/Plugins.cfg", "Conf/ogre.cfg", "Conf/log.txt") 
	Ogre.ShowConfigDialog() 
	TResourceGroupManager.LoadResourceFile("Conf/Resources.cfg") 
	Ogre.initialise(False) 
	Graphics Ogre.width, Ogre.height
	
	'TRenderWindow Setup
	Global opts:TNameValuePairList = New TNameValuePairList.Create() 
	opts.insert("externalWindowHandle", String(GetActiveWindow())) 
	Global mainRenderWindow:TRenderWindow = ogre.createRenderWindow("mainWindow", ogre.width, ogre.height, ogre.FullScreen, opts) 
	
	'Initialize resources - Do this after the render window is created in case materials require shaders, etc.
	TResourceGroupManager.InitialiseAllResourceGroups() 
	
	'Scene Manager
	Global mainSceneManager:TSceneManager = ogre.createSceneManager(ST_Generic, "MainScene") 
	mainSceneManager.setShadowTechnique(SHADOWTYPE_STENCIL_MODULATIVE) 
	mainSceneManager.setambientlight(TColourValue.Create(.2, .2, .2, 1)) 

'/Initializing Ogre


'Setting the Scene
	
	'Get the root scene node for attaching children-
		Global RootNode:TSceneNode = mainSceneManager.getRootSceneNode() 

Fingers crossed this will be the last compatibility test till we release a proper demo :).

NOTE. If you have problems, it's worth consulting the log.txt file in the root/conf folder.

So far it runs perfectly on the following cards.


Not so well on these:



If your having problems feel free to email your Log.txt file to adriantmaxATyahoo.com for troubleshooting.

Direct X worked fine for me, but OpenGL doesn't produce a window or anything.
Radeon X1950 Pro

Hi Po, thanks for the info, I updated the original post with some extra information at the bottom. Hope your experience isn't a sign of things to come.

Seems to work fine in DX9, apart from the VSync setting is ignored, even in fullscreen. It's disabled whether I set it on or off. Perhaps that's intentional for testing purposes. There are a few shadow errors in OpenGL, but nothing major. Also there are a lot of artifacts rendered with offset mapping enabled, although not quite as bad as the screenshot above, but I guess you're aware of that. That's with both OpenGL and DX9, by the way.

But yes, a few glitches aside, it works fine on my 8600 GTS.

The Offset map shader looks the same in shader FX .fx files, so I think it’s the shader itself causing the odd double base edge artifacts not ogre. I'm assuming that’s what you meant. Thanks for testing, seems like your card works as it should so I’ll add it to the list.

Oh, is it a ShaderFX shader? I can't say I was ever a huge fan of ShaderFX but I never noticed any artifacts before. On the other hand, I only played with it for a week or so. Have you tried another normal map? Could just be the map.

I might try another map, that one was from the shaderFX samples. regular normal maps work just fine. Our exporter uses shaderFX but creates better optimized shaders than shaderFX's FX files, and supports a lot of native Ogre parameters that .FX doesnt.

Here's a pic of the same normal map texture without using the offset stored in the alpha channel.
pic here

Both Direct3d9 and OpenGL worked perfectly on my system.

Hey Evak, OpenGL on the bumpmap still doesn't work for me, it shows the ground as black. So really it shows the robot only, My card is an ATI Radeon X300 (128mb)

Direct X works fine thou, and looks lovely still :-)

Works here without any problem including bumpmapping on my tablet

Pentium-M ULV 1.5 Ghz
Intel GMA 900 64MB Shared
1GB RAM
XP Tablet 2005 (XP Pro SP2 featurewise)

Works fine in DirectX, both windowed and fullscreen.

OpenGL works fine-ish in both, too. The only problem is the shadows. The whole screen is in shadow:



Compaq Presario laptop; 1.4GHz dual core, 2GB RAM, 384MB Intel GMA X3100 graphics, Vista Home Premium.

Well, seems like this one is working better than the previous version. I suppose OpenGL is going to cause a few problems around the board as it is less compatible than DX inside Windows, but of course we want to minimise these problems!

Works ok in both modes, but I don't see the bumpy floor, its just flat bricks.

Nvidia Go 7600 SE 256MB

Did you press R boomboom?

Cygnus: its interesting that for all others the DX one works better. on my system it just crashes with the runtime error or the repetition error (posted the pic in the previous thread).
If you have an idea what might causing the error let me know. (the window actually appears but only its border, the content does not appear and then the runtime error pops up)

Dreamora, whats the last few lines of your LOG.Txt file?

I can't see the image in the other thread- the image doesn't seem to exist. What spec machine are you running?

[edit]

Just saw the picture, that is odd, and I have no idea what might be causing it. What graphics card are you using? when using windowed mode I assume you are setting the Bits per Pixel to the same as your desktop?

thats the last part of it.
Specs:

Pentium-M ULV 1.5Ghz, 1GB RAM, Intel GMA900 64mb shared (PS 2.0, no hardware vertex processing, this means with pure hardware processing it will crash, mixed mode is maximum), XP Tablet 2005
And yes, the bpp are the same as the desktop

No idea what changed between the first version and the new ones dx implementation wise

EDIT:
On my mainsystem (Core2Duo 2x 3Ghz, 8800GTS 640MB, 2GB RAM, XP Pro SP2) everything works without problems.

I have the same issue as GFK, with last version, as well as with this version. Can try again later and give specs (need to rush to work).

I have 2 laptops I can test it on.

no i didn't, ooooo so bumpy (works in both gl and dx).

Kinda off topic, you can use http://www.crazybump.com/ to generate a normal/displacement map for the brick texture :)

I am so excited now :)

works fine here

and its selfshadowing ,cool

works great here.

Yep, the issues I found on the previous test is now gone, so everything works as spected.

OK, great, things are looking much better with this version. Keep testing people! :D

Sillyputty- hm, the light is just not working? not at any angle?

Here's the screenshot dreamora posted, moved from the previous thread.





Thats on a GMA900 64mb shared, interesting that it works on another GMA900.


With GFK's fullscreen shadow problem,

Linna thinks it's an issue with the driver missreporting the card and causing shadow volume calculations to be off.

I wonder if removing the default Ogre.cfg in the /conf dir would ensure that it doesn't try to use the existing.cfg in the archive which is for my 7800GS.

I removed the cfg file from the demo zip. Dreamora's DX problem seems a lot like the problem I have when lina commits her Ogre.cfg to SVN by mistake.


@ Dreamora and possibly GFK

If you have time to spare, could you remove the Ogre.cfg file from /conf and run the demo again. I think that the existing .cfg may prevent the detection of your intel card.

Can't you ask BRL for a Flow 3d module channel? I guess this would make sense as i suspect there won't be only two threads on this as it's likely there will show up more and more problems time after time like it's common with these things.

Just to have a safe home for this...

Maybe a bit later on, Taumel- it may be required :-)

Tried deleting Ogre.cfg - made no difference.

Damn, thanks for trying GFK.

i use a nvidia 5700

and work fine dx and opengl

Didn't help here as well, no difference. The chip was correctly recognized as the launcher will point the error out when you try to start it with your 7900GS in :)
Did something fundamental change between the "dx brightness" broken version and the one now? especially from the import point of view or lib / dlls its linked against?

the only difference installation wise to my main system is that no Visual Studio and DX SDK are installed (and that it is a tablet xp version)


At days like these, one starts to see why large companies invest in unreal technology and the like. might be expensive but less expensive than fight the incompatibility yourself most likely ^^

OpenGL works for me on the latest version, although DirectX now crashes (same error as before) regardless of the resolution selected. (Bumps & shadows -- looks niiiice!)

@Cygnus
Believe me, it will be required...

Both DX and openGL work OK for me.
Radeon X1650XT

(and I remember again why I hate 3D games -- even the ~20 second demo made me nausious and caused a lingering headache. :-?

Worked fine on my GeForce4 MX 440 card in both OpenGL and DX9 modes. The OpenGL version ran much slower though (with both versions set to 1024x768x32).

Runs fine on DX and OGL modes on my Radeon X1950Pro (AGP) card. Looks good. The ground isn't the same as the screenshot and there are no instructions printed at the top.

Will the ogre plugins work with the flow wrapper?

Some will work straght up, some may require wrapping (we're not wrapping *every* plugin for ogre- wayyyy too much work!)

Xlsior, Bill, Grey- Excelent, absolutely fantastic to hear it is working well! Thanks for testing. :-)

Works smoothly in Wine 0.9.56 on Ubuntu 64 bit. Nvidia 8600M GT, Intel Core 2 Duo T7500. Nothing really exotic, but it runs in Wine, which is good :)

Heh, that is kind of cool :). Might have fewer compatibility issues than a proper linux port and the various linux flavours ;P

They just released a new maintenance release, Ogre 1.4.7. I expect we will have that up integrated in the next few days, once Lina has gotten over the excitement of her new PC. This release seems to have a lot of GL and D3D fixes, some of which might have helped with the issues we had in the earlier build.

Ogre gets updated roughly bimonthly, mostly bugfixes since the next major ogre 1.6 version in CVS is quite far along now.

Here's the logged error that I get with DX9:

11:08:14: OGRE EXCEPTION(3:RenderingAPIException): Failed to DrawPrimitive : Invalid call in D3D9RenderSystem::_render at ..\src\OgreD3D9RenderSystem.cpp (line 2720)

The card is a 'Mobile Intel(R) 915GM/GMS,910GML Express', running on WinXP, just so you don't have to go hunting through the old thread.

thanks Sledge that is very similar to Dreamoras problem. I expect we will update the demo after we update flow to Ogre 1.4.7. I Havent been able to find any specific reason for the error message you two are getting.

The only reason I could think of is that the engine was switched from mixed vertex processing mode to hardware processing mode, because the GMA 900, while having a pixel shader 2.0 unit, has no hardware vertex processing, it offloads that to the CPU -> straight crash when you try to use it and don't check the caps upfront.
As mentioned, the original demo worked, so the fixes applied due to dx ground brightness problems must have changed something on that end if this helps to localize the "source" of this issue.

The ground brightness issue was a scaling issue on the ground, but that is interesting about the crash. We'll look into it.

I'm not really sure about the groundplane. We don't actualy know where the original mesh called .simplebox from the first demo came from.

I created an actual plane myself, that seemed to fix most of the lighting discrepancies between GL and D3D. I only recently started using shaders, and one thing I did do with this new plane was to save it with binormals, tangents for shaders, and edgelists for shadows. Perhaps the binormal or tangent info forced the mesh to be processed in hardware.

I'll look into this some more.

well, shaders are no problem, if they are Pixel Shaders.
But the GMA 900 has no vertex shader unit (processes them through CPU) and therefor only mixed vertex processing.

Don't ask me who came up at intel with that stupid idea. It is the reason why the GMA900 is not vista aero capable as well as it prevented it from getting the WDDM certification.

Some news here ? I have looked at Blink 3d and i like it.
But the price is to high.

I was interested in Blink3D before because its designed to run in a browser but never looked at the price because it took a long time to load the demos.

At the moment were discussing whether we can get Flow released fairly soon. Couple of loose ends to tie up plus Lina wants to get some half decent docs and examples so people can pick Flow up easily.

We also managed to contact Mark regarding the demo, and the Blitzmax demo is going to be updated soon :).

Were have also been discussing how we want to release Flow. We really want everyone to be able to try it and use it even with just the demo version of Bmax. So at the moment were considering a time limited demo version of flow that lets you run your apps for 2-5 minutes similar to how the old Jedive ODE physics editor did only for a longer period.

Perhaps having the full version downloadable in a similar way to Blitz through a website login, or SVN type affair.

Hope to have more info and to release Flow fairly soon.

Thanks for your answer, i will wait patiently.

I get no bumps on the floor in both modes, everything else works. I have a ati x1950 pro.

the only error in the log is

hmm, I'll ask lina about that. I made the HLSL shader with an artist friendly tool and Lina converted it to CG for me.

So far it has worked well on almost everything we threw it at that supports pixel shader 2.0. Do you get the error in both D3D and GL?

The shader even works on the mac when the demo is run in GL using crossover games (Wine equivalent on OSX) and also runs in GL on GMA 9xx intel chipsets.

Is the .OSM format something from ogre? for all I know blender doesn't convert to .OSM so that would be a put off for me to consider buying Flow.

Afaik OSM is an scene format. Flow still uses the OGRE mesh format for meshes but you can use the FlowED to contruct levels from meshes and save them as OSM.

Regarding OSM, You may also use .Scene files.

Blender doesn't convert to OSM, but FlowED that comes with Flow does.

OSM is the file extension for the Ofusion Scene loader, which is itself pretty much what Puddings Extended B3D was for Blitz3D- extra features, functions, and a very handy system for users of 3DS max.

OSM is more advanced than the typical .scene format and is used by our commercial 3dsmax exporter. We will probably add .scene support later. But Flow development has mostly been driven by a commercial project and was always primarily for our own personal use.

FlowED that comes with flow lets you make a scene from scratch out of regular Ogre meshes.

You can choose your scene manager, set up your global world settings, sky type, shadow techniques etc, and load individual meshes static, or skinned, create lights, cameras, particles and instances of any entity and do simple heirarchy rigging then both save and load XML .OSM scene files. OSM also has a binary format that can be compiled from the standard .XML scene files using a seperate utility.

.Scene is something we have been considering adding in addition to .OSM. They both come with sceneloader and scene serializer libraries and interface with Ogre in a similar way. Flow uses the OFusion Pro Sceneloader/Serializer libs which are still compatible with output from the CE (community edition).

Hey Evak,

Do you know when the Flow is release?

Probably somewhere this year I would guess.

Lol, We were thinking closer to ASAP. Still lots of preperation to do, bugs to fix etc though.

Yeah, hoping for weeks rather than months. I'd like to think we could be ready for some kind of pre release in about 4-6 weeks. Doable if all the recent lib updates work as they should.

Any details available yet on pricing for the engine, Evak?

We havent really settled on a price. Currently were hovering around $80 for the full version, and juggling a few ideas which might not be final.

At the moment it looks like the demo version will be fully functional, so you can compile whatever you make with it, but only run it for a few minutes, possibly with some kind of splash, marketing screen at the end of the timed session.

To release an actual product you would have to buy it, but anyone will be able to try flow fully before they buy.

We're also considering releasing the Bmax source for the editor with the full version, so people can extend the editor to suit their own requirements. The demo version will probably just come with a free runtime version of the editor, which we will also release to the ogre community.

We should have a flow portal web page ready for release that will offer Wiki, docs, and accounts page for updates similar to how this Blitzbasic site works.

Thats pretty much where the team has gotten with discussing release plans for flow.


NOTE:
Scratch the 4-6 weeks. Same week as I posted that Lina took off for 3 weeks holiday with no advance notice. So I guess were back to sometime in the hopefully not too distant future.

woohoo this little test works great (well the shadows anyway, no normal maps; both DirectX and OpenGL) on my machine, I can't wait to get my hands on flow!

WindowsXP, AMD Athlon 64 1.8GHz, 1GB RAM, Nvidia Geforce 6600

looks great on both modes for me...

NVIDIA GeForce 9600GT
3GHz P4 processer, 1 GB ram
windows XP