Over the past few weeks the Flow3D Mac port has slowly started to take shape; I’ve had to learn some Objective-C in the process, but it’s been rather easy so far. Flow3D is at the point now where it compiles well as a dynamic library under XCode, and now it’s just a matter of getting native OSX window functionality working as well as it does in Windows. Now that the boring stuff is out of the way, have a screenshot!

Picture Showing Flow3D Running in Mac OSX

I’ll report back when the Mac port is a little closer to beta testing phase. Also keep your eyes out for a Flow3D maintenance release this weekend!

Have Fun!

Lina
Flow3D Technical Lead

Well, the past couple of days I was supposed to be updating FlowED- however, things don’t always go to plan. Instead I found myself looking at mesh generation.

From the bog standard ManualObject demo I churned out a plethora of functions that draw and texture shapes using pixel coordinates, similar to how Max2D works. Emulating Max2D in Ogre probably isn’t going to be 1:1 because of the differences between the systems, but we’ll get close, and it will still of course be easy. Functions I wrote and tested were:

fG.Init2D()
fG.SetMaterial(Material:String)
fG.DrawRect(xPos:int,yPos:int,Width:int,Height:int,fill:int=false)
fG.DrawOval(xPos:int,yPos:int,width:int,height:int,edges:int,Fill:int=false)
fG.DrawLine()

I had fun writing these small functions and wrote a little example so if the interface is agreed upon, it may just see the next release.
The next thing this bought up was 3D mesh creation. To start with, I tasked myself with creating an easy CreateTerrain function. What I came up with was a CreateTerrain function that takes a 2 dimensional array containing the heightmap, and spits out a textured terrain with the same dimensions as the array.

The result was quite tasty, and I’m pretty sure this is what I’m going to use to create a slightly more realistic water demo- something I’ve wanted to do for a long time- you can expect more on this in the future.

The next step will be implementing the CreateMesh, Addvertex, Addtriangle, vertexnormals etc. These are the juicy bits- These alongside dynamic materials mean we could be generating some mean looking landscapes in code….

If you have any ideas or requests with this stuff- drop it in the forums where we can give it the old once over.

Over and out,

Damien.

Yes, I just wanted to show off more physics in FlowED. I didn’t count the amount of cubes, but its pretty nice watching it all fall when being hit by a Mini!

Here’s a quick video showing the improvements in performance since yesterdays video.

Yes, aha! I’ve managet to get physics working realtime in FlowED. This proved quite an easy task since the editor had been quite streamlined over the past few months.

It’s using Newton Game Dynamics 2 and the latest Flow. and will be released with the next Flow Beta.

Here’s a video of me fiddling around with it very shortly after first getting it running.

Well, I’ve almost completed the small gameplay tutorial code now, it’s in the Flow3D SVN. Last night I took some time to add a couple of sounds and somewhere along the way I figured I’d see just how much of an improvement Newton Game Dynamics 2 is over its predecessor.

The video below is the result- with Newton Game Dynamics 1, my system - an Intel Core 2 Duo E8400 at 3ghz CPU with an Nvidia Geforce 8800 graphics chip, would struggle with 200 blocks, achieving a very stuttery 2-10fps. with Newton Game Dynamics 2, I managed 600! blocks at nearly 30fps- and in all honestly it seemed even smoother than that!

Note that stacking a wall the way I have done in this video really stresses Newton too, where if I was to simply stack the blocks in columns it would be even quicker!

Today will just be a quick update that expresses a few key additions to the Flow3D package as of late:

We have recently updated the Ogre3D rendering engine in Flow3D to use the latest production version, 1.6.0 (Shoggoth)! With this comes things like better script compiling and more effective memory allocation, amongst other things.

Along with the Ogre engine update, we have gotten some soft (texture) shadow demos working and simplified the implementation a bit with fG. With properly setup .material files to allow the shadows to be received, all you must call to get nice, soft shadows is this:

fG.enableSoftShadows()

Ah, fluffy shadows, the 16,720th wonder of the world.

On to physics! We will be updating to Newton 2 within the next few days, so make sure to look out for a few videos within the week! While the update to Newton 2 is not yet complete, we have added simple ball/socket joint creation in fP with a small demo to go along with it. Have another screen shot!

The code for creating a basic Ball-Socket joint works a bit like this (taken from the demo):

'Create the socket from Socket.mesh
Local Socket:TEntity = fG.LoadMesh("Socket" , "Socket.mesh")
fG.PositionEntity(Socket, 0, 2, 0)
fG.getNode(Socket).Roll(90)
Local SocketBody:TBody = fP.addPhysics(Socket)
 
'Create the ball from Ball.mesh
Local Ball:TEntity = fG.LoadMesh("Ball" + String(i), "Ball.mesh")
fG.getNode(Ball).Roll(- 90)
fG.PositionEntity(Ball, 0, 2, 0)
Local BallBody:TBody = fP.addPhysics(Ball)
 
'Create the socket joint specifying the parent and the child.
'By using the defaults here we ensure that the joint bodies won't collide with one another.
'We also ensure that the joints position is the midway point betweent he two bodies' positions.
Local joint:TBallAndSocket = fP.addBallSocket(SocketBody, BallBody)
 
'Here we set the rotation limits of the joint by specifying the direction of the joint pin.
'We also allow 80 degrees of "swing" space and 45 degrees of "twist" space in the joint.
joint.setLimits(Vec3(1.0, 0.0, 0.0) , Radians(Deg2Rad(80)) , Radians(Deg2Rad(45)))

And there you have it! Get those ragdolls crackin’!

I hope you’ve enjoyed this preview!,

Lina

Note: The code types specified in the code boxes is not correct. BlitzBasic was just the most syntactically accurate highlighting scheme available at the moment.

Hey there! I’ve been busy at work with Flow3D all day today, as the Flow3D demo release is coming up and we all want to make sure there are no documentation and implementation holes. Today I spent a lot of the day tightening up the basic Particle System handling and I thought I’d give you a little preview of how particles work in Ogre and thus in Flow3D!

First off, the most common way to handle particle systems in Ogre is to use a template file, which can hold multiple particle system definitions. Template files look a little something like this:

File: Spark.particle
 
Spark
{
	quota	50
	material	PE/lensflare
	particle_width	.5
	particle_height	7
	cull_each	true
	renderer	billboard
	billboard_type	oriented_self
 
	emitter Point
	{
		angle	99
		colour	1 1 0.821918 1
		colour_range_start	1 1 0.821918 1
		colour_range_end	1 1 0.821918 1
		direction	0 1 0
		emission_rate	50
		position	0 0 0
		velocity	30
		velocity_min	30
		velocity_max	70
		time_to_live	0.3
		time_to_live_min	0.3
		time_to_live_max	0.3
		duration	0.3
		duration_min	0.3
		duration_max	0.3
	}
 
	affector LinearForce
	{
		force_vector	0 -100 0
		force_application	add
	}
}

And whew, that was a mouthful. And while it seems that that would be painfully difficult to type by hand, if you check the Tools section of our site you’ll find plenty of Ogre particle generator tools out there - most of which are excellent for getting the effects you want. In fact, Spark.particle was generated with such a tool.

To load Spark.particle in Flow3D using fG is relatively painless. First you make sure that the .particle file as well as the material (PE/lensflare) that it references are in a resource directory that Ogre can get to, and then you simply call:

Global ps:TParticleSystem = fG.loadParticleSystem("myParticleSystem" , "Spark")
fG.PositionEntity( ps , 0 , 50 , 0 )

The code above will create a spark particle system, and then set it to (0, 50 ,0) in world space. I could have left off all of the positioning information, but it is rather unlikely that you are going to want to create a particle system at (0,0,0) all the time.

Now let’s discuss a few of the things I added in today. That is, let’s discuss manually spawning in particles from a blank particle system that we have created using fG. The code below is the full code, which compiles and runs on a BlitzMax install that has the flow.main module installed.

Import flow.main
fG.init()
 
'Create our empty particle system and give it a mask texture
Global ps:TParticleSystem = fG.createEmptyParticleSystem("ps")
ps.setMaterialName("jet")
 
'Call to renderWorld to init the created particle system
fG.renderWorld()
 
'Spawn four particles in a cross shape
'fG.createParticle( TParticleSystem , Direction , Size )
fG.createParticle(ps, Vec3(0, 100, 0) , 75.0)
fG.createParticle(ps, Vec3(0, - 100, 0) , 75.0)
fG.createParticle(ps, Vec3(- 100, 0, 0) , 75.0)
fG.createParticle(ps, Vec3(100, 0, 0) , 75.0)
 
'Basic renderloop
Repeat
	fG.renderWorld()
	Delay 1 / 60
Until KeyDown(KEY_ESCAPE) Or fG.appTerminated()

The basic visual generated by the code is below:

While the render loop is a bit crude, the application successfully spawns four particles which spread across the screen in four directions. It is fair to say that if you find that the params for setting position, direction and velocity are not enough with createParticle(…), createParticle(…) also returns the TParticle that was created, which you can manipulate like so:

Global p:TParticle = fG.createParticle(ps, TVector3.Create(100, 0, 0) , 75.0)
p.setTimeToLive(2.0)

Anyways, that’s all the time I have for now! I hope this has been of some interest to you!

Lina

While we haven’t paraded the release date everywhere, we’re hoping to release the FlowEd beta sometime this weekend ( December 12-14, 2008 ). Slowly, we’ve worked our way down the checklist of features and issues until it was empty, and now we’re primarily in the internal testing phase.  After release, you’ll be able to test out FlowEd for yourself and any feedback you can provide will be greatly appreciated.  The fastest way to give the team feedback will be to post in the FlowEd -> Issues and Requests forum so that we can itemize desired features and catalog the issues users encounter.

I will keep this post short and sweet - so I leave you with a random sceenshot of the current FlowEd SVN build. A little smoke on the water never hurt anyone. Well, yes it has, but you get the idea.

“Do crab cars have steering wheels on the side?”

-Lina

Where Damien posts stuff.

Here’s where Lina posts her stuff.