3DEngine Demo's - What would you like to see?

Miscellaneous Forums/General Discussion/3DEngine Demo's - What would you like to see?

Hi All,

I Hope this isn't to premature!

Just for reference: FLOW is well written Ogre wrapper (Plus essentials) for Blitzmax. EasyFLOW will be FLOW with a Blitz3D like commandset that will be released a while after Flow.

Flow comprises of Ogre3D, Newton for Physics and Cegui for GUI. There will also be FlowED for Scene editing

We have just started coding some of the tech demo's for Flow. I was wondering what you generally look for?

If you have any ideas for these demos, or even, what you would like to see in a tutorial, let us know. We will select the best and do what we can!

[edit] I'm talking code and running examples here mainly ;-)

Examples below!

Tutorials:

>Basic framework (Includes All of the below.)
>Setting up resources.
>Setting up a new scene.
>Loading (and Animating) a Mesh.
>Loading a scene file.
>Shadows etc
Tools:

>Material browser.
>Scene Editor

Things are a fair way off at the moment but this gives us plenty of time to prepare things for you all. Thanks all!

I would like the 'basic camera+cube' example to see difference (if any) with Blitz3d (as starting point - or minib3d).
Then I will add the others features (shadows, lighting, shaders...) with (if possibile) the same example running in Blitz3d (or miniB3d).

This should be enough to see performance and syntax of your engine.
(remember: I'm not a 3d engine expert, and B3d is the ONLY 3d sdk I have used - so for ME - this is the milestone).
Just my opinion.

Thats OK, Any ideas will be listened to.

Flow however, is not really like Blitz3D, so anything that is more suited to the Blitz3D system will be taken note of for the later EasyFLOW system.

Wasn't Flow the name of that Flash game that was put on the Playstation 3?

Anyway, I think what you're going to want to illustrate are a) features and b) how easy it is to use. If it takes a year to learn the thing and you can't know much about it without having worked on its internals, then you're selling a corpse pretty much. Now I know, some people like to buy corpses, but that's a minority.

The point is that you shouldn't be going for basics, cover every possible angle you can think of that will say "this is why you need Flow." Personally, I don't need Flow (I could make so many jokes about that name, by the way), but if I were in your position, I'd aim for illustrating
- the art pipeline
- how many animated meshes can be onscreen
- shader support and how low you can go hardware-wise without losing the visuals you get with shaders
- sound support (considering Flow is more or less an OGRE wrapper [you guys are really asking for it with that name], this may be none at all)
- ease of use -- if I start coding with it right now, am I going to be able to get stuff going quickly and easily?
- flexibility -- even if it's easy to use, how much freedom do I have to really customize what's going on?

That should get you started.


Wasn't Flow the name of that Flash game that was put on the Playstation 3?



I have no idea.

Thanks for your comments Noel, you make some good points. Something tells me you don't like the name. :P

I don't mind the name, but I can't help but think of a certain female quality when I read it. I doubt others are near as, er, likely to see that and think of various lines that would go great at my family's dinners and horribly at any other's.

I'm sure thats just your dirty teenage mind.. haha. :P

..I like it dirty baby .. :)

Bah to you old fogies! Anyway, ought to be interesting to see how this turns out. I'm going to go the heck to sleep, 'cause staying up 'til 6am for several nights in a row tends to take its toll on sanity. If you need someone to horribly abuse it, let me know and I'll break it so miserably you'll.. I don't know, do something to respond to it being broken miserably.

You will need details on how to implement (and find) a suitable collision detection system.

Or physics, such as Tok, ODE, Newton... 3D sound etc... I doubt you'd get many customers if you only supplied a wrapper around Ogre, as there are many more aspects to producing a 3D game than just the rendering component.

Just my 2p.

Cheers guys. I'm noting it down but I think perhaps I gave the wrong impression- What would you like to see in code, and running?

As for physics, OgreNewt is part of the system. note that Flow is an Ogre wrapper, not an entire game engine.

Hi, I second the shader system. For example terrains ;)

Other than that, the simple comparison between standard easy to use blitz commands and how many "steps" would be needed for setting up simple scene (simple being cube, camera animation and collision).

If you guys can add that physx thingy, I think I would stick to it.

Is flow cross platform or just windows?

Thanks and good luck!

My initial thoughts for flow were to do a series of smallish demos that show off various aspects of the wrapper. Also showing a series of basic gameplay elements that are coded in a simple straightforward not overly OO fashion that beginners to intermediate Blitz3D coders can understand.

Things I was thinking of including were.

Physics,
Collisions,
Shooting,
Mouse-look FPS,
Simple 3rd person camera,
Particles,
CEGUI skinned UI, simple HUD, using MaxGUI with Ogre
Simple animated character
Basic vehicle physics
Using Bmax keyboard and joystick input

Either showing these things separately, or making a demo that incorporates all these features in some way, Kind of like the Blitz3D and Blitzmax demo’s.

The world editor would be to make it a lot more straight forward for people to create levels by placing the objects and storing them in the two most common Ogre3D scene formats, plus making it compatible with the excellent 3dsmax art pipeline tool Ofusion. Creating media for Ogre is easy enough, there is an extensive range of tools available for free and commercial modeling and texturing tools, The world editor is the one thing that I feel the ogre community hasn’t catered for very well.

If we were doing the simple demos, (with nice graphics) we would obviously include the Bmax sources and make the demo’s easy to follow for beginner-intermediate coders.

Much of the documentation can be found in the Ogre API, but we already have begun on flow specific docs and tutorials.

One of the things in Flow that I’m most pleased with is compatibility with MaxGUI and ogre running in a blitzmax window, plus you can mix GUI systems with CEGUI (scriptable skin based gui system) allowing for a lot of flexibility with how you use the wrapper, that and that it uses Blitzmax’s own input, audio etc systems.

The simple world editor seemed like a good way to demonstrate these windows/GUI features.

This makes it all the more easier to pick up and use.

Or physics, such as Tok, ODE, Newton... 3D sound etc... I doubt you'd get many customers if you only supplied a wrapper around Ogre, as there are many more aspects to producing a 3D game than just the rendering component.



Flow currently has Newton physics and collision support, there may be alternatives avaliable later on. For simple collision you can do scene manager raycasts.

Audio is covered by blitzmax native sound, or whatever modules become avaliable for it.

Input is also handled by Blitzmax.

We basicly tried to get everything possible done on the blitzmax side of things for ease of use and user familiarity.


Is flow cross platform or just windows?


The C++ side of FLOW was developed with cross platform in mind, currently we only have PC's to develop on, but our main C++ coder would like to support the others too.

Hi, I second the shader system. For example terrains ;)


For terrain, the paging landscape scenemanager has been the solution thats most likely to be implemented.

Ogres rendering optimizations are controlled via scene managers, you can use existing ones or create custom scene managers, or mix and match scene managers as you see fit.

SHADERS

Flow Supports the same vertex and fragment programs Ogre does both low-level programs written in assembler, and high-level programs written in: Cg, Direct X 9 HLSL, or OpenGL GLSL.

So there is no 3d sound with Flow?

Not unless theres a 3d sound mod for Bmax, we havent looked at sound past whats already in Bmax.

There are options for ogre but whether any will be implemented in flow, no one has brought it up before and at this point its not a priority.

I agree to that- A render engine doesn't tend to include sound :)

3D sound is of interest to me though. I may look into it at a later date myself, but thats due to my own interest :D I can't say i'm fond of getting users to install stuff like OpenAL if they don't want to though.

Hi, for 3D Sound: Maybe you take a look here: http://www.blitzbasic.com/Community/posts.php?topic=68838

Its a small 3DSound Module for miniB3D based on OpenAL but it should be easy to convert to any other 3DEngine.

Material browser.

I'm sure we can manage some kind of simple material browser viewer :)

I missed that, sorry (or are you adding ideas to the original post?)

I updated the original post, yes. Thanks. :) Any ideas that we think are useful I will ammend the first post with.

The scene stuff sounds good.

Are you going to have basic tutorials for animation and shadows and stuff, or is it going to be intuitive enough for those sort of things?

Yes there will be tutorials for things like shadows etc, though they are generally quite easy!

Demos need to show that Flow is handier and more effective than Irrlicht module.

-AF

I'd like to see an apostrophe in the correct place! ;-)

Good luck. Look forward to seeing it.

Demos need to show that Flow is handier and more effective than Irrlicht module,


Well, this goes without saying. If Flow isn't more powerful/usable than an already existent module then we've failed.

>Demos need to show that Flow is handier and more effective than Irrlicht module,

That means the module will be expensive due to the workload of coders/artists.

BTW, I hope FLOW can be a single DLL instead a s**t load of DLLs set....

Hello,

I would like to see dynamic mesh creation/destruction, this one thing is missing from most engines. Otherwise basic morphing/vertex interpolation is nice also.

@Cygnus
I don't know. 3D Sound for sure isn't as important as the gfx but it somehow is part of the overall experience. It's a little bit like having lights without shadows in a 3d engine. It works but it's not really a satisfying solution.

- An adjustable water plane (height/texture/RGB/alpha) for the world editor

- Fog with adjustable RGB, thickness and near/far distance

We've put a little screenie of the start of FlowEd up in the showcase.

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

Looking good m8! Mark's got competition already eh? :)

Hi, this one looks really going in the right direction for me :D

Any chance to add that physx wrapper Render did? Would be cool to see an all in one solution.

the editor won't have physics on release, but since source will be included it shouldn't be too hard to add.

The initial version of flow will come with Newton, but there has been talk within the team to support other plugin physics libs. Physx and maybe ODE.

The current plan is to have Windows and Mac versions, assuming we can get a universal binary version of ogre to behave with Blitzmax. Will know for sure closer to release. Linux too if it behaves and doesn't cause too many compatibility problems between linux flavours.

Yeah, I think we are all interested in the Physx stuff, and since its hardware accelerated, it might come in handy for a few people as the hardware becomes popular.

How about a submarine moving in a lagoon slightly too fast, trying to decelerate and 'surface', failing to prior to reaching the edge of the lagoon and simply rebounding (instead of crashing) at a decelerating speed ?

I see theres been talk of no physix in the early release, but good luck with your product, it already looks quite accomplished from your link.

heh, we didn't say no physics, just no Ageia PhysX since we want to remain cross platform. Physx is windows only, so were sticking to Newton Dynamics Engine which is Windows, Linux and Mac compatible.

But you can make PhysX compile for osx. Actually Unity's physics engine is PhysX and runs both on win and osx. I'm sure you can make it run on lin as well. There might be licence issues which you have to work out first.

Question: How tightly coupled are the graphics and the physics in FLOW?

As for tutorials... you'll want a good, meaty tutorial on shiny materials. Everyone likes materials, and they take some real skill to get right. A tutorial like that creates confidence that it is indeed possible to do them, even if someone (like me) has no ability to do the artwork. Another worthwhile thing to demonstrate is materials on complex objects. (Not just built in cubes and spheres).

(Yes, I have just resurrected a 2 month old thread. That search function is great now!).

Amongst others i would like to see the supported shadow methods shown and information on what they actually run on. What are the minimum specs? On which platform will they crash or do you prevent the usage there (thinking of all the nice openGL drivers on the win side)?

Things which demonstrate how featurerich and stable the engine is in real world situations and not only on a developers computer.

Evak,

at the risk of repeating stuff - I havent read the rest of the thread, the single most important feature of any complex software is VERY GOOD TUTORIALs - written for users and not technicians.

You cannot have too many tutorials and not on how to print you name or "hello world." Stuff which real users would want to harness, i.e. probably the features which you are USPing your engine to feature.

Good luck with that.

IPete2.

When?


...and: will it support Mac?

Any news Evak?

We're still working on this guys- its just more work than we anticipated.

I think we have enough ideas for demos now, but any more are welcome!

Code samples and discussion of setting up advanced features (shaders etc) to work together would be more useful to me than examples (as nice as they would be). :)

Hey there, how is this coming along? I started looking into using OGRE with BlitzMax, because OGRE has a lot of flexibility in terms of the art pipeline (eg. I can export animated characters from Maya), and found this thread. I'm certainly very interested in FLOW.

Still going! We don't want to release until it is ready for consumption, as we speak I'm working on the scene editor app FlowED that will come with Flow.

More information soon.

Cross platform?

How much it'll be, and how big it'll be, OGRE is famous for it's size....

Price isn't the main consideration, A little game with 10MB of barebone(exe+dll and compressed) is too huge for me.

Oh yeah, I second D4NM4N's question. Another area of flexibility that I like with OGRE is that it is cross-platform. Will FLOW retain that cross-platform aspect?

@D4NM4N, jhocking:Yes, We are aiming for flow to run on Windows Mac and Linux.

The price hasn't been decided so i'm not going to be detailing that just yet.

As for the size, well, Ogre can be shrunk down quite a bit by removing the dlls you dont need to use- but its not going to be possible for it to be smaller than a barebone ogre installation. I havent done a size check yet but I can certainly check that when I get home- I'll make a barebones app and see how small I can get it. :-)

A barebones Ogre application (OgreMain.dll, OIS.dll, Plugin_OctreeSceneManager.dll, RenderSystem_GL.dll) is about 4.68 MB unzipped, and 1.75 MB zipped.

But often you'll want CG shader support, DX9 and OpenGL, particle effects, GUI support, etc., in which case Ogre's DLLs total about 10 MB. But again, Ogre's DLLs compress very well, in this case down to a 3.7 MB zip.

P.S. Cygnus / Evak: What level of terrain, tree, and grass support is planned? Do you intend to integrate any of the PagedGeometry library's features at any point for fast tree/grass rendering?

At the moment we are working on the core Ogre functions, we've thrown Cegui in for ease of use when it comes to libraries- other plugins may follow at a future date.

PS It's Evak haha.

Yes, those sizes sound about right- I think Evak posted them a while back but I couldn't find the information straight up.

Also, we're trying to avoid using libraries to deal with keyboard/mouse/joystick in favor of keeping blitzmaxs internal events working with the ogre window- again for ease of use and familiarity.

PS It's Evak haha.

Oops sorry about that, how did I get that mixed up :)

Also, we're trying to avoid using libraries to deal with keyboard/mouse/joystick in favor of keeping blitzmaxs internal events working with the ogre window- again for ease of use and familiarity.

Yeah, that's good.

What I would like to see is something that shows the simplicity of the art pipeline etc.
A "simple" graphical flow would already be enough.

Most engines always focus on eye candy, yet forget about their art pipeline and how complex this end can be.

Worst case for that are B3D and Torque which tend to need several conversion steps in between if you don't waste money on 3000$ applications.

Were making a world editor with some simple 3dsmax like functionality. If you look at the main toolbar and are familiar with max you will recognise some of the basic tools.



Simple screenshot shows you the UI, was pleased that we got auto # of dynamic light, position, colour and attenuation working in a simple modular method with our shaders.

Ogre is a little more complicated than B3D to set up a scene. It is nodebased, so you create a scene node, give it a name and attach your mesh/light/camera etc to the scene node and transform the scene node.

To make it simpler, we are using some libs that come with the Ofusion 3dsmax exportet. The scene loader and Scene Serializer (saver) library. This will allow you to use either 3dsmax to export your scene with an amazing array of WYSIWYG functionality and load it into the editor. Or build scenes from scratch from within the editor and save out new scenes.

As well as being an object placement editor, you can also set up simple heirarchical linking of entities. So you can rig your vehicle with a child camera, mount nodes, wheel nodes and body parts using the link and unlink tools. Edit light and camera node parameters etc. You can then save out your Gameplay objects as a seperate .OSM scene files if you wish.

Same with your levels and lighting setupsm they can be saves seperately and merged at runtime, allowing you to have multiple skies and lighting setups for a scene.

All the heirarchy of rigged objects is maintained with multiple scenes and you can select items in viewports, use CTRL to add items to your selection, use gizmos to move and rotate items, SHIFT drag to make an instance of your current selection and duplicate heirarchies or whatever about your scene etc.

And all these items can be accessed with code in a similar way to what your used to in Blitz3D only with a kind of visual editor thats usefull for level designers and in some ways reduces coding clutter when setting things up.

The editor uses the scene loader and serializer lib thats kept up to date with the commercial Ofusion exporter. And supports a lot more features than we will be releasing the editor with.

Were hoping that the editor will bridge the gap making ogre easier to use with a powerfull extendable XML based scene format.

In the initial version of the editor we will have a usefull basic tool set, and are considering having it as an open source editor for registered users.

The scene format supports too many things to list here at the moment, but will load any meshes created with regular ogre mesh exporters.

To reduce the code clutter of manualy creating scene nodes for every entity and attaching entities via code, when you load a mesh into the editor, scenenodes are automaticly created for you. Modelers that support a local pivot will position the scene node at the position of the local pivot. Simple modelers that don't allow editable local pivots will put the scene node at the world origin, so you will have to export your models with 0,0,0 coordinates where you want your pivot/scene node to be. Transforms and rotations will be from that point.

Anyway, we think this will be a really nice tool for people wanting an easy way to work with Ogre and Blitzmax in a B3D kind of way.

Thats the basic functionality we have finalized for the initial release of Flow and FlowED. There may be some nice extras in there on release though.

I like the sober look and the round edges of the windows. Some icons could need some rework, for instance the rotation one.

I second the request for PagedGeometry.

-AF

You will be able to use custom scene managers so John J's paged geometry scene manager isn't out of the question, Flow already supports automatic and manual static geometry batching with regions etc. As does the .OSM scene format.

Cool :)

-AF

How is the status as we are nearing Feb 2008 ;-)

Really hope it plays out well for you :)

Will FLOW come as a standalone SDK?
Will we be able to use a standard c++ dev enviroment or is it bound to blitzmax?

@Swampdonkey. Since FLOW is an Ogre wrap, there would be no need to use it in C++ since you can just use Ogre. :-) [edit] If you are talking about the editor, FlowED won't be tied to blitzmax. It's written in Bmax but it'll be a tool for the ogre community too.

@Dreamora. Still moving forward! Unfortunately I have a day job too on top of this and things got busy during the final couple of months of last year, so we are a little behind. It's frustrating (for all of us!) but what can you do?

Any news on that?

Yup. I'm still at my Dayjob.

Really, we're just a bit overwhelmed with how much work this has been. It's been a year since the original post! We do have a few things left to do but do not want to release this while it has that "incomplete" feeling.

Lina has been working really hard getting the docs up to date, and I believe we're about to update to the latest Ogre.

Pesonally I'm anxious to release- It's surprising how hard a 1:1 wrapper is hehe. All I can say is I hope you all enjoy it.

There's a game demo we're making with it, MazeMonkeys, and this is a current screenshot.




Also, Thanks for helping regarding Blide Ziggy, your latest fixes will ensure Blide and Flow are an awesome match!

waffles!!!

I'd like to see:

1. A way to set up a scenegraph with entities, and then finetune the materials.
2. A simple way of saving/loading the scenegraph's entities.
3. Terrain system with LOD/ROAM and texture splatting.
4. LUA/Python scripting.

I'd buy anything with those features, which could also be used in BlitzMax

I want a demo that shows:

- Godrays
- Volumetric Fog
- Buoyancy Planes
- 128 or more Lights (and their shadows) visible at the same time
- SSAO
- Parallax Occlusion Mapping
- more than 3000 physics bodies moving
- FPS over 60 when doing all the above at the same time

If it can do those, you got a new customer, else I'll just stick with LE2 and keep pushing Josh to implement all of the above (some have been done already).

Lord, Crysis comes out and everybody wants those features for their bedroom projects. Haha.

Why not head over to www.ogre3d.org to see what the renderer can do? :-)

[edit]

128 lights? link me to something that can do 128 lights? I can't think of a scenario that would need anywhere near that many.

Also, buoyancy planes is physics, not rendering. However, we're including Newton, so you can do that.

Actually, if you read the OGRE3D manual on shadow maps, all they support are spot lights. Directional and point lights are both drawn as a simple spotlight. In fact, their implementation is so bad they tell you not to use it:
http://www.ogre3d.org/docs/manual/manual_69.html

Generally we recommend avoiding making point lights cast texture shadows.


There is a pretty good soft texture shadow tutorial demo that works well with point lights. We havent gotten around to implementing it ourselves yet because none of us are too got at shader programming.

http://www.ogre3d.org/phpBB2/viewtopic.php?t=39809

The official ogre demo is very confusing indeed. Especially for someone like me who isn't much of a coder. Lina who is the only one of us familiar with shader coding said she would take a look at the demo posted above, and we might implement it as an option for high end systems and high graphics material scheme in our demo. Problem is that I havent got a clue how to use shaders unless I use my shader plugin for 3dsmax to create them. And I believe the texture shadows need some editing in my material source.

So far I've only played with modulative stencil shadows, because my shader knowledge is too limited and I don't know how to seperate ambient, lighting and diffuse passes in my shaders required for additive shadow types.

The bad thing about OGRE in my opinion is the art pipeline. The guys from NeoAxis (a .NET wrapper) knows about that. I´m looking forward to see FLOW, btw. Best regards

What's wrong with the art pipeline? Neoaxis is pretty cool- used it quite a bit myself.

MESH files can be exported from alot of apps.

Ofusion OSM can also be exported from 3DS max with the ofusion scene exporter.

Al Meyer, where do you have a problem with Ogre's art pipeline? Interested because Ogre's art pipeline tools have improved dramaticly in the last 2 years that we have been using it.

Ogre has a good pipeline from most tools. We have an editor to make scene creation easier. And although our editor uses OSM scene output we want to support .scene loading which will let you save scenes from several other apps too, but use .OSM as the native flow format since it supports so many more features.

Ogre actually has more and better exporters than blitz3d. Including all the popular 3D apps. 3dsmax, maya, lightwave, XSI, Blender. Plus cheaper hobbyist tools like milkshape, Giles. Ultimate unwrap supports Ogres xml mesh format, which means that if you have an obscure app and want to convert to ogre you can easily, and use the current binary mesh compiler to get your media upto the latest mesh version.

The biggest difference between blitz and ogre is that meshes and materials are seperate entities and use a seperate scene file to store the scene data. This does take a bit of getting used to. The sceneloader in flowed lets you load scenes from within zip files, and will recognise zip files with a different file extension. Plus the scene format comes in binary and XML formats. Flow comes with integrated sceneloader and serializer libs which make things a lot simpler than straight ogre.

You can also create scenes manualy in FLowED, and edit the XML scenes in your favourite text/Xml editor if you wish.

Materials are simple scripts, some exporters take care of writing scripts for you so you never need to edit them by hand.

Well, Evak, it´s my opinion. Ogre only allow its format. Blitz allows 3DS right out the box. There´s a discussion about it on NeoAxis forum about it. Here is not NeoAxis, so I will not go further. I`M REALLY INTEREST in FLOW, and certainly will bought as soon as it come out. One of reasons I put NeoAxis aside is that matter, but it is personal. Look at my post *** The bad thing about OGRE in my opinion is the art pipeline *** . I put MY OPINION :)
I would be happy when I test the Flow engine and chamge my mind.

ah yeah, but the native ogre mesh format is one of Ogres strengths when your used to it. Since it contains a lot of engine specific data that ageing generic formats like 3ds and obj etc don't.

I used to feel the same way as you originaly so I see where your coming from. Cygnus and I looked at neoaxis a fair bit too, but found the reliance on resource editor for setting all media very cumbersome. I actually posted on the forums there hoping they would support one of the two commonly used scene formats to make using neoaxis editing a lot faster. But they don't seem that interested.

Anyway, hope you like flow when its out :)

> Anyway, hope you like flow when its out :)

You can count on me. I´m doing my first game on Blitz3D, and i will stick with it, mainly to learn, but I´m looking for another stuff for other projects. I really interested in Flow. A easy to use OGRE based engine will be great.