GOOF Editor Updates (Now available in ogreaddons)

Falagard

04-10-2005 05:46:34

UPDATE

GOOF Editor is now available in ogreaddons.

See the wiki page for information about what GOOF is, as well as installation instructions.

http://www.ogre3d.org/wiki/index.php/Ga ... _Framework

Still a very early version.

Jerky

07-10-2005 18:00:21

I'm very much interested as we will need this tool very much. Keep up the good work.

I will try to find some help for you, since I do not want to be a mooch :) (and I am no programmer). Our programming team is lacking atm, but we will bounce back.

Crashy

07-10-2005 18:07:42

There may be others.
Terragen can be used to generate lightmaps.

Falagard

08-10-2005 07:19:47


Terragen can be used to generate lightmaps.


I need meshes to cast shadows onto the terrain, Terragen obviously doesn't do that.

As a new update, I've added my tree rendering technology to the game object framework... which of course means it ends up in the map editor.

The technology is similar to SpeedTree on the rendering side - it uses a vertex program to rotate quads towards the camera giving the illusion of a tree. Here's a really old demo of it in action:

http://www.larabie.net/ogre/LegendsOfTa ... Demo01.zip

It is being updated to work perfectly with the game object framework, including levels of detail and billboards for distance trees.

The process of creating trees is actually pretty easy, but you need to use a 3d modelling program of some sort (anything that can be used to export .mesh files). You create a trunk mesh, then create a special mesh for the leaves where each vertex of this mesh ends up being the location of a leaf quad, then run it through a tool I've created and presto chango, awesome looking trees.

The same code will be used for camera oriented grass (locked so it only rotates along the y axis). Of course there also will be fallback code for non vertex program capable cards if you want to support them, which means you'll need an alternate less good looking version of the tree as a traditional mesh. In my case I'm generating this version of the tree in a program called TreeMagic G3 found at aliencodec.com for around $60.

So what the TreeGameObject actually does in the Game Object Oriented Framework is the following:

Checks if you support vertex shaders, and if not falls back to a different mesh that potentially has a set of its own LODs.
If supports shaders, loads the vertex shader cool looking leaves version tree.

Clay

Jerky

08-10-2005 07:29:02

Absolutely awesome. That is another must on our list. I have just been researching trees this week. I'll take a look at this. Thanks for the updates.

*edit* It looks great! Which way are you doing the treegen? Are those billboards?

Crashy

08-10-2005 10:02:59



Terragen can be used to generate lightmaps.


I need meshes to cast shadows onto the terrain, Terragen obviously doesn't do that.


Ahh ok, you want the lightmap of terrain+objects, I thought terrain only, sorry :oops: :oops: :oops:

Borundin

08-10-2005 10:27:44


Here's a really old demo of it in action:


Wow that really looked good and the performance was much better than I wouldve thought. Checked the ogre.log and it seems like I got on average 200 fps. Even doing alot of zooming into the core of the tree.
I like the idea about SpeedTree in OGRE 8)

Good work!

Jerky

08-10-2005 20:17:53

@Falagard: Any chance I could get my hands on that Tree tool Falagard?

And.... what items do you need help on? I have asked one of our programmers to focus specifically on this issue (an editor), so he should be showing up soon. We, internally, have a City Editor that places and rotates meshes into the world, but my suggestion was that the functionality be merged with this one. In your opinion, is that a good or a bad idea?

Since I am no programmer, your input would very useful, especially since our experience with Ogre is nowhere near what yours is.
jerky_at_projectwish_dot_com

Falagard

13-10-2005 20:41:36


Any chance I could get my hands on that Tree tool Falagard?


Yes, but don't expect magic. It's not a tree generation tool, it's a tool that takes an existing tree and starts rendering quad billboards that face the camera for leaves using a vertex program.

It's going to be integrated with the GOOF framework, or you can pull out the code if you wish, so yes you can have it.


..functionality be merged with this one...


I think it depends on timing. I'm working very hard every night on this framework because I want to get something done soon so I can show it off. But although I may have a tech demo ready soon (within the next couple weeks), the code may be a bit off. I will release the code I have at any point (even right now if you want) with no guarantee you'll be able to get it to compile. But putting together a true release takes time, readmes and instructions and support - so I wouldn't expect a true release in less than 6 weeks.

Falagard

13-10-2005 21:05:16

Update: October 13th

As I described before, I'm integrating my Tree rendering code. At the same time I've realized I needed to spend some more time on the LOD code because previously LODs were only done at the Page level. This means that the page decided whether all objects on the page would switch LOD or not. This works well for static geometry in the far distance, and I figured that I'd use Ogre's built in entity LODs for regular meshes. When I started implementing the Trees I decided I want to change how the LOD system works in the framework.

I'll try to describe how LODs will work briefly:

For a single mesh object, such as a rock - Instead of specifying an arbitrary number of meshes for the different rock LODs, and the distances for each LOD, you basically just specify a size for the rock. The size determines how many LODs you should provide, and the distances at which the LODs change.

Example:

VeryLarge size has the following LODs:
VeryLow, Low, Medium, High
Large size has:
Low, Medium, High.
Medium size:
High, Low
Small size:
High

The LOD distances for each size are set up in a config file for the framework.

Imagine a house. You specify the house is a large object - the system assumes you'll provide three LODs, so when the house is loading it checks in the config file for the house (the .meta file) for high, medium and low lod mesh file names. If some aren't provided it will default them to the closest found LOD file name.

Also, the system has been designed to only load meshes when they're necessary. For example, you may have 16 pages currently visible around the player, but only 3 are in the "immediate" area. The 13 other pages will have loaded the .objects file for each page, and the objects will have been instantiated, but MeshGameObjects are smart enough to only load the entities that are needed - so for example, if it's a MeshGameObject that has been specified as "small" it will not load its entity until the camera is closer. If it is "large" but in the distance, it will only load its lowest LOD.

So far so good, this system was basically already in place but only working at the Page level.

I'm in the middle of updating the system so that pages in the immediate area, which could be several pages depending upon the position of the camera, will check all objects on the page every X milliseconds to see if they need to change LOD. I always knew this change would be required but it became completely necessary for trees, which will have special LOD handling. I also plan on fading in and fading out entities as they switch between lods and/or disappear using a vertex shader, if available.

So, after this LOD update goes in, it'll be back to implementing trees.

Clay

tuan kuranes

13-10-2005 21:29:13

Seems great.

Just want to point out that if using big static geoms of trees, you might want to separate trunk from leaves.

A forest of trunk is a good occluder (fast to render and solid) but leaves aren't (costly to render and even lot of them would let some pixel passes by as they're small.). Unless you use the operation flashpoint forest LOD trick (from far forest is a big mesh, near to a mapped cube)

Anyway if you're using CVS you can try all those combinations using the CHC algo. (look how it's activated in the demo, using "end" key.)

On the same topic, Don't forget to include static/moving, occluder/non-occluder in object properties...

Falagard

14-10-2005 00:13:59

Thanks for the tips!

The leaves are currently split from the trunk, just by chance though :-) I'll make sure it's done by design for both the fancy and the fallback trees.

I will definitely look at the occlusion culling stuff as soon as I get the LOD and tree systems in place, because I want to actually put the occlusion culling to use :-)

I assume you've done some tests, is it working? :-D

Clay

tuan kuranes

14-10-2005 07:56:01

yes. it give rather good result with random mesh on terrain
But need test with real data to tune some activation heuristic or not

Falagard

18-10-2005 07:31:58

Okay, finished my LeafGenerator tool, created a TreeGameObject and added code for orienting billboards towards the camera in a vertex shader into the MapEditor.

So my trees are working - needs a bit more work but I'm happy to show a video of it in action:

http://www.larabie.net/ogre/TreesInMapEditor.wmv

Also notice at the end of the video I drop in a couple little bushes and they fade in and fade out with the LOD code I put in.

Not sure why but as soon as I started capturing the video with Fraps the terrain disappeared. *shrug*

tuan kuranes

18-10-2005 08:25:33

Really superb and very smooth fading, loving that.

fraps does work here with terrain, make sure it's not a key conflict by remapping movie key shortcut to F12 for example.

Jerky

18-10-2005 15:18:41

Absolutely awesome. Keep up the great work!

Falagard

18-10-2005 19:08:55

Thanks guys!

I'm going to be putting in special LOD switching tonite which allows fading between mesh LODs. Currently, it fades out when it should no longer be visible, and fades in when it goes from invisible to visible... but I'm going to add the ability to fade between LODs - which means that the current LOD fades out to invisible at the same time as the next LOD fades in to visible. This will then be used by Trees to switch between Tree LODs and is the same thing that SpeedTree does for its LODs.

Fading is tricky - I don't know if I mentioned it but I take the original entity and clone all its materials temporarily during the fading process... then modify the materials to turn on alpha blending and modify their diffuse alpha. That's all fine and dandy for fixed function, but for vertex shader materials I'm going to need to do something different. I'll still clone the materials but I'll attempt to set a vertex shader constant called "opacity" if it exists, and the shader will have to be coded to use that constant for its visibility. Tricky.

Oh ya and I also want to put in special billboards that use a vertex shader for the lowest level of detail for the trees. And um... then work on fallbacks for the TreeGameObject when the user doesn't have a vertex shader capable 3d card. Lots of work damnit!

Haha, good point regarding the keys conflicting for Fraps

tuan kuranes

18-10-2005 19:47:36

I'll attempt to set a vertex shader constant called "opacity" if it exists, and the shader will have to be coded to use that constant for its visibility. Tricky.

Perhaps you can juste use a "Distance to Cam", which is outposition.z and use it as an opacity factor

here's how I did that in DecompressVertex.cg in plsm2/media,
FogSettings[0] being a constant defining the max distance. (use here to fade detail texture to transparent as camera is far from terrain.)
oPosition.z is the output position of the vertex shader.


// saturate() works just like clamp() apart from that it implies a clamping between [0;1]
float opacity = saturate (1.0 - (oPosition.z / FogSettings[0]));

Falagard

18-10-2005 20:19:15

Yes, I'd thought about that and decided against it for a couple reasons. One is that I'd rather the switching between LODs happen quickly instead of being dependent on camera distance, and it better ties into my code which loads and unloads meshes based on LOD distance. This also means it works the same way for both fixed function and vertex shaders.

Also, I'm planning on using the z distance from camera for grass though, which will work differently than most other meshes in that it will be created in large blocks of static geometry. In the case of grass I will be doing exactly like you suggest - fading it out based on distance to camera ;-) For fixed function in this case I'm not sure exactly what I'm going to do for grass though.

Clay

tuan kuranes

18-10-2005 20:34:52

Forgot the different LOD mesh, I was thinking about same mesh and same material using the same vertex shader and texture for batching reasons. Your choice is indeed better.

About grass, did you see Serious Sam 2 latest demo grass and tree LOD ?
(second demo, out today, not the first demo)

The grass is not only fading but also being less dense.
The less dense can be done in fixed function LOD using different "grass densification", and have a rather good visual impact, compared to standard far cry or battlefield all fade-in / fade-out that make grass sort of "growing" in front of player (which is sort of annoying.).

For trees they have a stranger LOD : main trunk fades in first, then whole tree fades in, but without foliage and only then foliage fade in. don't know if I like it...

But grass is neat, a bit repetitive though.

Falagard

19-10-2005 05:24:29

Okay, just downloaded the serious sam II demo, yup I see what you mean. That should be easy-ish to do once I get grass working.

Slicky

19-10-2005 07:25:44

I need help understanding what this tool would be used for? Is the terrain already created and you add objects to it? What else are you doing that adds to the experience?

I saw your video and it looks like you've put some time into this tool. I like the little fade in effect.

Falagard

19-10-2005 16:25:31


I saw your video and it looks like you've put some time into this tool.


You have no idea :-)

http://www.ogre3d.org/wiki/index.php/Ga ... _Framework

There's a page that describes GOOF and a bit about how it integrates with the MapEditor itself. Lucky Luciano put most of the work in the Map Editor for its terrain editing features, I've been adding object management features so you can place objects, like meshes.

Falagard

20-10-2005 17:25:40

Got cross fading between LODs working the other night, and last night I got it working with vertex shaded materials using an "opacity" value passed into the programs. Looks good, and works with textures that are using alpha rejection as well .. without blending.. using a trick I am borrowing from SpeedTree. If you mottle your leaf texture with grays specs - the leaves seem to dissolve as the alpha changes, even without blending. Looks good ;-)

I downloaded SpeedTree's Trees of Pangea demo last night and played with it. I had played with it before of course, but this time I noticed a few interesting things that I hadn't before.

They're doing fancy projected texture shadows similar to Ogre's texture shadows but with a higher end pixel shader to blur the edges of the shadows. I had originally thought I'd be calculating shadows onto the terrain using lightmaps, but after seeing how well this works I've changed my mind. I'd rather see if I can get this technique to work. It needs special consideration for trees using this billboarding technique though because afaik they can't cast shadows properly... will need to create a shadow texture for the leaves that is used instead of the real geometry.. but still leave the trunk as real.

That Trees of Pangea demo is my target - holy crap does it look nice. A long time ago I tried out some SpeedTree stuff, and while it looked nice, their leaf shaking didn't look that great, the textures weren't that hot, etc. Now I'm blown away. If I can get anywhere near as close to that I'll be happy, and I think that the only things holding me back are:

Shadows on the trees and on the terrain.
High resolution textures for the bark, normal maps, and a pixel shader for lighting them.
Fake branches using textures - they make heavy use of fake textures for branches and it looks great.
Shaking leaves. This will be interesting.
Grass - included textures projected onto the grass.

That's it for now.

Falagard

24-10-2005 19:10:12

Just working through some bugs related to my LOD changing stuff. Bug fixing isn't as fun as feature adding but it's necessary. So far so good, fixed a couple nasty ones. One crash bug left and then I'd like to get billboarded lowest lod trees working and put together some type of massive forest :-D

Cross fading between tree lods looks pretty good IMHO.

After playing a bit of Jade Empire I realize that I want to create grass that parts at my character's feet as he runs.

I have a good idea on how to do this with vertex shaders. May post on the main forum for feedback.

Clay

Jerky

24-10-2005 20:35:01

I downloaded some of the free xfrog trees and am working with them right now. I am also going to create some of my own trees using textures that I will create from my digicam photos. I was in Colorado all weekend, so I got some good shots (8MP) that should be of some use. If you want some more for your demo (or use), let me know. I will be using ZBrush at some point to create highres normal maps for my trees.

BTW, great work. The Trees of Pangea demo is what got me as well. I have a couple of their old ones and my thoughts were the same. Kinda so-so. This newer demo is just amazing though. Any goal that is anything near how that looks is a good one.

Falagard

26-10-2005 16:12:44

Update: had a couple nasty days trying to track down the worst bug ever. No real progress - been slowing disabling features to try to track this one down, and so far I've disabled background loading, collision detection, fading LODs, etc. and still having this crash. Hopefully tonite I'll have more luck.

@Jerky, thanks for the offer for photos, I may take you up on that.

I've gone out several times and taken photos of trees - in fact the leaves o the trees in that video are from photos I've taken. Same goes with grass, etc.

I've taken a look at XFrog as well, and it was my original plan to use XFrog. The only reason I'm currently planning on using TreeMagik to produce the tree trunks is because it will also create leaves for me that I can use as a fallback when a user doesn't have vertex shader support on their 3d card.

I am planning on having normal maps for my trunks, and do per pixel normal mapping on the bark using the sun as the light source, so normal mapped bark would be awesome.

Not sure about using ZBrush though for normal maps. Do you mean using ZBrush's automatic high resolution mesh to low resolution normal maps functionality? Not sure if that'll work, cause you'll want this high resolution bark texture to be tiled on the tree, and it'll have its own normal map, and then ... you want to make a second normal map for bumpy knots and stuff on the tree or something?

Clay

Falagard

01-11-2005 05:07:56

Still tracking down bug. Was out of town over the weekend so didn't get much done. Worked on it tonite, added tons of debugging output to try to track it down.

*EDIT*

Found and fixed the bug about an hour later.
Starting to put back in functionality and see if everything is acting nicely still.

*END EDIT*

duff

04-11-2005 15:40:10

Hi,

I am working in a team of mmorpg project using ogre.
and we need to have a good map editor.
So, i think i will take the current one and add missing features to allow our team to use it.
Where can i find a cvs or svn of it ? I have read that it is on ogreaddon but do not seen it.
Is the version of cvs up to date?
Which task i can take in it?
what Os map editor support?linux? windows?

thansk for answer ;)

Falagard

08-11-2005 01:11:53

It's not currently available in CVS or SVN but it will be by the end of the month if you're willing to wait.

It *should* support linux or windows because it is written completely in Ogre, including the user interface using CEGUI but I haven't compiled it in linux yet.

Should be simple to port though.

Regarding features, take a look at:

http://www.ogre3d.org/wiki/index.php/Ga ... _Framework

That's mostly the current feature set with some places where it may say that it's not complete.

Some things that need done are:
Shadows on terrain using texture shadows. This will require features added to Ogre to support texture shadows of alpha masked textures.

Character animation for the Actor class to hook up running, walking, jumping animations to the actor while he moves.

And much more but those are two that I can think of.

Clay

Falagard

12-11-2005 04:45:44

Update:

Okay, been out of the country on business in Australia for the last week and haven't had as much time as I wanted to to work on Map Editor and the GOOF framework.

However, I'm currently working through a list of crash bugs in order to be able to release this even though it's not where I wanted it to be. I don't think it'll be available by the end of November though, I'm going to have to delay it a couple weeks.

I have broken a lot of the systems but rewriting the metadata stuff to share data across all instances of objects. This means I have to go back and fix the various objects, such as particle systems, lights, markers, sequential objects, etc.

I fixed the Actor object which allows 3rd person movement when in simulation mode, so that's good. It wasn't working on uneven terrain. It does still need work but it's in a working condition now.

Prefabs need looking at, as well as any sort of hierarchical parent/child stuff is currently crashing on load.

I have the whole weekend to try to fix some of these things, so cross fingers, hope everything goes well.

Clay

tuan kuranes

12-11-2005 06:59:29

we're all crossing fingers ;)

Falagard

13-11-2005 23:49:01

Fixed most of my major bugs. Added awesome Tree functionality to automate the generation of leaves. Calculates leave shadows using ray-casting and creates a cached mesh which will then be used every subsequent time.

Jerky

14-11-2005 00:11:59

Wow, sounds awesome. We cant wait to get a chance to check out all your hard work. Keep it up!

Falagard

14-11-2005 15:25:37

Here's an example of how to create a tree for use in GOOF. You can of course use whatever process you like for creating the trunk and leaf meshes, but this shows an example of what I did for a tree.

First, I used Arbaro, an open source java application for generating the trunk mesh. Took a couple hours to learn how to get anything nice looking out of Arbaro, but it does make better looking trunks than TreeMagikG3 does, which I was using previously.

So I generated a tree in Arbaro and exported to a .obj file:

http://www.larabie.net/ogre/ArbaroScreenshot.jpg

I think imported the tree into 3ds max and scaled it up to the proper size. The green box beside the tree in the screenshot below represents a human's height, so I scaled the tree until it matched what I expected this tree's height to be.

http://www.larabie.net/ogre/MaxScreenshot.jpg

I manually added "fins" to the tree mesh which had a branch texture mapped to it. This adds fake branches that are very low detail but look fairly good even close up. Got this trick from SpeedTree.

Here's a shot of it in max in texture mode. Some of those branches are full geometry, and some are just fins.

http://www.larabie.net/ogre/MaxScreenshot2.jpg

I then created a leaf mesh using a bunch of spheres which I booleaned together using "union" to create a single mesh that doesn't have overlapping internal polygons. Each vertex in this leaf mesh will end up generating a leaf billboard when it is loaded in by the TreeGameObject in GOOF and displayed in the editor. As you can see this was done fairly quickly with no attempt to really make it look pretty. Also, I ran the multi-res optimizer over it to lower the polycount down to something reasonable.

http://www.larabie.net/ogre/MaxScreenshot3.jpg

I don't have a screenshot for this, but I then cloned the trunk and leaves meshes and generated a low poly trunk mesh and a lower poly leaves mesh by running multi-res over the trunk and leaves mesh and further lowered the polycount. All of these were then exported from 3ds max as ogre meshes.

I then basically have to create a little .meta file that looks something like this:


<MetaData ObjectType="TreeGameObject" Name="Tree3">
<TreeGameObjectData LeavesHighLODMesh="Tree3Leaves.mesh" LeavesMediumLODMesh="Tree3LeavesLow.mesh" TrunkMeshObjectMetaID="Objects\Meshes\Tree3Trunk.meta" LeafTexture="Leaves.tga">
<LeafDefinition Top="0" Right="1" Bottom="1" Left="0" Width="0.4"/>
</TreeGameObjectData>
<PagingGameObjectData SizeHint="Large"/>
</MetaData>


Now I'm able to drop the tree into the scene in the map editor. At this point the tree object needs to generate new meshes based on the leaves meshes in the config file. This is done automatically - the tree object loads the high and low level of detail leaf meshes and for each vertex, generates 4 new vertices with special parameters used by a vertex shader when it is later being rendered. This creates a billboard at each vertex in the leaf mesh. It also automatically generates shaded leaves by taking a sun direction and creating spheres at each leaf point, and performing ray casting using opcode to see if the leaf should be fully lit or shaded. In the end a new mesh is created for the two levels of detail for the leaves. The next time the tree is inserted into the editor it checks if these meshes have already been generated and doesn't generate them again. If you want to re-generate them simply delete the cache of generated leaf meshes and it'll automatically re-generate them next time you drop in a tree (you have to re-start the map editor though for this to work currently).

Here is the final result - low lod:

http://www.larabie.net/ogre/MapEditorScreenshot1.jpg

high lod:

http://www.larabie.net/ogre/MapEditorScreenshot2.jpg

Video of the transition. Note that I'm running on my laptop which has a really bad integrated video card that can barely run anything, so with fraps taking the video I was only getting 8 frames per second. On any sort of real 3d card this runs very quickly. Also, I stopped moving coincidentally before each LOD kicks in... there is actually no slow down when switching LODs, I was just stopping to be sure I didn't move too fast past the trees so you could the transition between lods.

http://www.larabie.net/ogre/MapEditorTree.wmv

CrxGames

30-11-2005 03:08:47

Wow, looks great :D.

CrxGames

03-12-2005 20:15:22

Almost forgot, any new word on when there may be a release copy?

Falagard

04-12-2005 21:00:15

Sorry guys, you know how sometimes RL intrudes. It's been hectic here for the last couple weeks so things are going to be pushed back at least a few weeks for the GOOF and MapEditor stuff while things settle. Wife and kids, real life job, etc. plus christmas hastles have slowed down progress.

Rest assured I'm still working on it, just that it will be pushed back another couple weeks. I originally said an alpha late November, then mid December, now it looks like it'll be early January. Sorry :(

Clay

kiolakin

04-12-2005 21:26:20

Any chance of just getting the most recent compilable version in CVS so the rest of us can help ? Or does it just not compile for me ? :/

Falagard

05-12-2005 02:28:43

The version in CVS is fubar.

No chance of just handing it to you because I haven't integrated with CVS in over 6 months. Which means I need to get the latest PLM2 in CVS and integrate and fix any issues with my code, and then have to submit to CVS.

It's one of the things on my list of todos before I can release it to everyone.

I can easily give out my current work in progress code, but it'd be up to you guys to figure out how to get it to compile and fix issues, which I doubt you'd want to do.

kiolakin

05-12-2005 04:34:03

Id be willing to be the "re-assimilation" person for MapEditor. Since the version in CVS is fubar anyway, if you post your code to CVS I'll start assimilating it to the PLSM2 CVS version.

I guess the biggest trick will be what do to after that... how to get the changes you are making off CVS while the assimilation is taking place without reversing the work that was done to assimilate it in the first place. The best way to do that would probably be to get a diff from the import date to the date we want to register in more of your code, and apply the changes to your new code and then look for discrepencies.

Yeah, I believe that will work. Why don't you blow away the MapEditor in CVS and reimport with what you currently have. I will take it apon myself to make that version work with PLSM2 while you continue to make updates on the PLSM2 that you already have. Once I get this code integrated we can generate a diff for the changes I have made and reapply it to your code. If all goes well you will be able to continue to update your code while I simultaneously work the integration with the new PLSM2 and the end result should require very little to combine.

Of course for this whole plan to work I will need commit priveledges on MapEditor... Anyone ??

Falagard

08-12-2005 16:30:29

Thanks for the offer to integrate the Map Editor back with Ogre CVS. I don't think the integration will be too much work but the Map Editor and GOOF stuff is pretty much in a state of some minor but code breaking changes right now. For example, back in March I released a demo of the Map Editor with the ability to add particle systems, lights, marker objects, and generate prefabs and all of those features are broken until I revisit some minor changes I made to how the objects save and load themselves. It'll only take me a couple days to fix these things, but it'll look bad to you when none of these features are working.

Plus there's a bunch of other things such as I have modified Ogre to add background thread loading and I'd like to release an example "world" with some sample objects to play with.

Regardless, here's my latest source:

http://www.larabie.net/ogre/MapEditor-SrcDec8.rar

Sarev0k

02-01-2006 07:51:27

I read the wiki article you wrote about GOOF and I'm intrigued. I could definetly see myself using parts of it for my project. I was wondering though (it doesn't seem to be mentioned in the wiki article), what license are you planning to release GOOF under? GPL, LGPL, Public Domain?

Thanks for the fantastic work your doing for the map editor and CEGUI. I look forward to see what you develop with the fantastic tools your making :)

Falagard

02-01-2006 19:44:42

I'll be releasing it under LGPL.

Glad to see you're interested :-)

Falagard

13-01-2006 04:55:01

Progress Update:

Working on various things that need to be done before I can make this available. The last couple days I fixed up the Particle system object so you can place particle systems again (it was broken) and at the same time added particle system level of detail. This basically let's you specify different systems for varying LODs, as well the particle system shtuting off after a certain distance (based on the size setting of the object).

Also spent a bit of time with the Particle Editor available here on the forums, to create a nice looking fire effect with smoke. I'll be turning this into an example prefab (2 particle different particle systems added together into a single prefab that can be inserted as one object).

Also fixed up some bugs with the Tree objects not saving/loading properly.

Next on my list is fixing prefabs. I broke most of the systems when I implemented the very useful metadata manager system and now have to go back and fix them, including prefabs, lights, sequential objects, and markers. The good news is that now that I have the particle systems working, it will be easy to do lights, sequential objects and markers since they were the type of object called RepresentativeObjects that have a visible draggable marker that disappears when in Simulation mode.

After that I'll do some general testing and bug fixing and I can release. I'm quite behind still though since it's mid January and I have only just started working on the editor again after a break.

Clay

Falagard

15-01-2006 21:33:06

Progress Update

Instead of doing prefabs, which was next on my list, I implemented sound objects. To do this, I took the OpenAL sound manager in the wiki, and the SoundManager Plugin from the forums, and merged them together into a hybrid of the two which takes advantage of the buffer management of the OpenAL wrapper and the ease of use of the SoundObjects in the SoundManager plugin.

Then, using the flexibility of the GOOF framework, I created a SoundGameObject class which can be added to the scene like any other object. I'm currently working on LOD stuff so the sounds are added/removed based on distance, which helps free up resources. There'll be some issues later on to work out, such as the fact that buffers never get freed in the OpenAL sound manager until the whole system gets shut down. But that can come later ;-)

So... next on my list. Prefabs. Again.

Jerky

15-01-2006 21:48:06

You are doing an excellent job. We really appreciate it. Once my programmers are finished with our city/object editor, I'll definitely point them over here to lend a hand, if you can use one.

Falagard

15-01-2006 22:15:31

Excellent.

What are your guys doing with your city editor?

The game I'm eventually making with this map editor and framework will have both rural and urban settings.

For the city, I was planning on putting together a snapping system where meshes are either modelled at certain dimensions and then you can turn on a grid snapping and angle snapping feature in the editor (which is not yet implemented) to "snap" the meshes to each other, or alternatively, use a system of named reference points on the meshes that know how to snap to each other, and have them snap automatically. Then things like buildings, roads, sidewalks, etc. will be done as meshes that will snap together and can be reused all over to create a city.

The terrain will likely be completely hidden below whole blocks of city roads, etc., only to appear in parks etc.

Another possibility is doing the whole city as one big mesh and then splitting it up in pieces and importing it into the editor all at once, then just use the editor for placing certain types of objects like lights, particle systems, etc.

I prefer creating nice reusuable snappable meshes though.

Clay

Jerky

16-01-2006 00:18:15

Here is the status as of Jan. 8, taken from our dev forums.
So what's done for now:

* Object (mesh) scanning for building object library.
* Simple object inserting (for now placing at world center).
* Fully working camera movement (maya style).
* Fully working multiple object selection system (using bounding boxes).
* Simple object moving on XZ plane.
* Fully working undo system.
* Saving scene into DotScene format.

Short term todo list (more or less priority sorted):
* Scene loading.
* Fully working redo system.
* Selecting axes to work on for tools like moving, rotating, scaling.
* Selecting world/object coordinate system for tools.
* Fully working object movement.
* Fully working object rotation.
* Fully working object scaling.
* Object inserting at interest point
* Object removing.
<-- first workable version

Long term todo list:
* Inserting light nodes.
* Snapping to grid.
* Ray-mesh intersection for accurate picking, object placement.
* Object property viewer/editor.
* Maya style object moving/rotating/scaling.
* Object in scene list view.
* Object grouping.
* Layers like in photoshop.
* Object properties locking.
Feel free to give your own suggestions/input.
I prefer creating nice reusuable snappable meshes though.
This is exactly how I invisioned it months ago as well. Saving time and resources by making pieces that can be combined with different pieces to create different whole pieces. I have relayed your info to our main programmer. I'll see if I can get you 2 to talk :).

P.S. I don't want to hijack this thread, so if we need to move it, np.

Falagard

16-01-2006 05:51:08

Feel free to post here for now, if it gets crowded we can move.

I'm interested in the undo system your programmer has put in. I've implemented two different types of undo systems in the past, one that was command based, where each operation that could be done in the editor had an perform and an undo function, and they were added to a stack.

For a more advanced editor, the operations start to get more and more difficult to keep track of, especially if a single undo transaction involves N number of operations. In this case the best undo system was one where the complete scene was saved after an operation occurs, and then you provide optimized routines for some actions, such as simple move/rotate commands, and then fall back to complete reloads of the scene when operations get too nasty to undo.

Clay

tuan kuranes

16-01-2006 06:21:59

just to pop in papers as usual : about city generation, check that very interesting papers and demo :
http://www.infinitylab.com.au/research/prototypes.htm

Falagard

16-01-2006 06:39:31

Thanks tuan. Kinda interesting, though if I start auto-generating boring cities, shoot me.

Also, were they trying to come up with the most painful control scheme ever, or did that just happen? :-D I find that a lot with research tech demos, really bad controls.

Anyhow, it was good to see the city streets in action. I think when I start to do my city I'll pop in GTA for inspiration. I wonder what that did for the Matrix Online? I've seen video of it, and read people saying the world was repetitive and dull looking, but Id be interested to see it in action just out of curiosity.

*Edit* Not that I'm a GTA player whatsoever, I have only briefly played GTA Vice City for a couple hours, but I thought they did the city pretty well. Ultimate Spiderman was pretty cool too. *End Edit*

Falagard

19-01-2006 06:23:33

Finished prefabs, started working on undo/redo system.

Also started looking at generic design for editor to uncouple it from terrain scene manager.

Falagard

19-01-2006 07:34:19

New editor architecture for working with any type of SceneManager. I'm sure no one will actually look at this and understand it until it's in a diagram, but trust me it's sweet. I'm going to start refactoring the existing code tomorrow to fit into this architecture. I've been meaning to do this anyway, but started working on the undo/redo system and realize it needs to be done sooner rather than later.


GOOFEdSharedLibraryDll project
(API to the editor for plugins)

classes:

GOOFEdApplication
registerPlugin(GOOFEdPlugin*)
activatePlugin(GOOFEdPlugin*)
addOperation(GOOFEdOperation*)
undo()
redo()
addToolTab(GOOFEdToolTab*)
GOOFEdPlugin
getName()
init(GOOFEdApplication)
activate();
deactivate();
bool frameEnded(const FrameEvent& evt)
bool frameStarted(const FrameEvent& evt)
void keyClicked(KeyEvent* e)
void keyPressed(KeyEvent* e)
void keyReleased(KeyEvent* e)
void mouseClicked(MouseEvent* e)
virtual void mouseEntered(MouseEvent* e)
virtual void mouseExited(MouseEvent* e)
virtual void mouseMoved(MouseEvent* e)
virtual void mouseDragged(MouseEvent* e)
void mousePressed(MouseEvent* e)
void mouseReleased(MouseEvent* e)
GOOFEdToolTab
CEGUI::Window* getWindow()
GOOFEdOperation
undo()
redo()

GOOFEd project
(editor application implementatin for GOOFEdApplication)
(sets up the scene manager, user interface, etc)

GOOFCoreDll project
(base classes for GOOF game objects)
(simple core implementation)

GOOFExtendedObjectsDll project
(game objects for mesh, lights, particle systems, sound, etc)

GOOFEdPagingLandscapePluginDll project
(implementation of plugin which knows how to edit terrain)
(DynLib automatically registers itself with the GOOFEdApplication)

classes:

GOOFEdPagingLandscapePlugin
(inherits from GOOFEdPlugin)
(gets registered with the GOOFEdApplication)
(sets up its tool tabs within the editor)
(When active, handles all mouse clicks, keys, etc. to raise/lower terrain)
GOOFEdPagingLandscapeLoadSaveTab
(inherits from GOOFEdToolTab. The new/save/load tab for terrain)
GOOFEdPagingLandscapeMorphTab
(inherits from GOOFEdToolTab. The terrain morph tool tab for raise/lower etc. terrain)
GOOFEdPagingLandscapeTextureTab
(inherits from GOOFEdToolTab. The terrain texture tool tab for painting terrain)

GOOFObjectsPluginDll project
(implementation of plugin which knows how to insert/delete/move/rotate etc. objects)
(DynLib automatically registers itself with the GOOFEdApplication singleton via registerPlugin())

classes:

GOOFEdObjectsPlugin
(inherits from GOOFEdPlugin)
(gets registered with GOOFEdApplication)
(sets up a tool tab for objects within the editor)
(When active, handles all mouse clicks, keys, etc. to modify GOOF objects such as meshes)
GOOFEdObjectsTab
(inherits from GOOFEdToolTab. The objects tool tab for managing objects)

GOOFBSPPluginDll project
(implementation of plugin which loads a BSP)
(DynLib automatically registers itself)

classes:

GOOFEdBSPPlugin
(inherits from GOOFEdPlugin)
(gets registered with the GOOFEdApplication and sets up a BSP tool tab)
GOOFEdBSPTab
(inherits from GOOFEdToolTab. The bsp tool tab for loading a BSP scene)

Falagard

20-01-2006 20:17:55

SpookyBoo - this is for you. I didn't copy/paste your private message but I'll reply here nonetheless.

Regarding the wiki GOOF entry, it's not a design, it's a description :-) I'll be putting together more information on the actual design later.

Regarding the difference between start and stop versus pause and resume, I can see your logic. However, I'd only add that if I ended up seeing a reason for it or if you could give me a concrete example. Otherwise people will just get confused about the difference.

About dynamic properties, yes, if I understand you correctly. In my case, I have a file called a .meta file, which contains a definition about an object. For example, I have a MeshGameObject class. I may have 3 meshes, house.mesh, fence.mesh and rock.mesh, and I'd create 3 meta files, house.meta, fence.meta, and rock.meta. The meta file for a mesh has data for the mesh file name, lower lod mesh files, the size of the mesh as used by the LOD system, collision mesh, whether it should cast shadows, etc. When a house MeshGameObject is actually inserted into the scene, it has a pointer to a Metadata structure that is filled with those values. Therefore 100 house meshes all refer to the same meta data instead having their own copies of that data. Plus the metadata file is parsed just once and then stored in memory. When the house MeshGameObject instance is serialized, it doesn't re-serialize all that data, instead if just contains a reference back to the original metadata. It's possible for GameObjects to allow the user to override the default values, in which case that property would actually be a member variable in the game object and serialized with the object.

Not everything inherits directly from GameObject, it depends on the object. ParticleSystemGameObject, LightGameObject, MarkerGameObject, and SoundGameObject need a visual object to drag around in the editor, but won't in the game, so they all inherit from an object RepresentativeGameObject which has a visual object when not running the simulation. I don't have movable versus static objects, but will add them if I need to. I have a IsStatic flag on MeshGameObject as well as CanCollide and Collide functions on the CoreGameObject.

SoundGameObject is not for when you walk on other objects, it's for when something has to emit a sound, such as a fire or a water fountain. I'd probably create a new type of object that each frame would detect what was under it and look up a corresponding sound. That object could then be added as a child to other types of objects, such as the ActorGameObject or whatever needs to move around.

Clay

Falagard

20-01-2006 20:44:12

More:

Instead of taking the approach where I force you to inherit from StaticGameObject or DynamicGameObject, instead I've decided to build in support for static geometry directly into my CoreGameObjectManager.

Regardless of what type of object you are, CoreGameObject has a function called enumerateEntitiesForStaticGeometry(vector<Entity*>& entities); which allows the object to add a list of entities that will be merged into a single ogre static geometry instance. If your object knows it has static geometry, it will call CoreGameObjectManager->addObjectForStaticGeometry(this) and some time later the game object manager will call enumerateEntitiesForStaticGeometry.

I'd use the same approach for other types of functionality that I deem should be used across multiple types of objects. For example, right now collisions are detected with a moving Actor by getting all the nearby objects, checking the canCollide flag, and then calling object->collide(actor) to see if a collision occurs. This means that CoreGameObject has the interfaces for collide() and canCollide() and by default just returns false for canCollide, and for collide() calls getCollisionEntity(). This is done instead of creating a CollisionGameObject that you must inherit from, or a Collision interface that you must use multiple inheritance to also inherit from. MeshGameObject returns true and creates a CollisionEntity from its mesh.

If this becomes unwieldy I can separate them - it wouldn't be hard but I'd have to probably go with multiple inheritance in that case, and I don't see it being necessary yet. I'm open to suggestions and flexible on the design and systems if the changes make sense.

Falagard

24-01-2006 07:08:16

Update:

As I posted earlier, I'm refactoring the code to be more modular. My design goals are as follows;

The editor should be embeddable.
Create an application framework for managing the game state so you can switch between major states. (examples of screens are splash screen, options screen, main game screen).
Create a standalone editor that uses the app framework.
Create a common library of code that is shared across the various systems.
The editor should be plugin based. Plugins register themselves with the editor.
Allow new tools to be dynamically added to the editor.
Refactor the terrain editing and object management windows I already have to fit into the above framework.

There's more but I've been told I type too much.

And wohoo - a screenshot of code!

tuan kuranes

24-01-2006 08:22:54

Thanks for keeping us informed !
Nice screenshot btw ;)

jacmoe

25-01-2006 00:47:00

I see that you are happily coding away! :)

Falagard

25-01-2006 01:55:46

Regarding the occlusion culling in PLM2:

I'm going to be using it in combination with GOOF's partitioning system which is used for loading and unloading objects as you move from one partition to another, as well as setting level of detail.

Currently it's being done based on the terrain page you're on. It's going to be refactored to be a generic partition system and to work for interiors as well but still using the Paging Landscape Manager. My plan is to let you place meshes for interiors and subdivide them into interior partitions, linking partitions together that you know are potentially visible. When you walk inside one of these areas it will set the LOD of everything outside to low, and start dynamically loading the interior as you move from one partition to another. Hopefully it'll work like magic.

I'd actually like to know if Tuan has other plans as well so that I can decide whether to continue with my ideas :-)

tuan kuranes

25-01-2006 13:02:35

@jacmoe : Paginglandscape finality is to mix freely terrain and interior, using the same manager.

@Hopefully it'll work like magic :
Idea of the CHC algo is to really helps optimizing both, but interior is the one who gains the most.

The Octree partinionning tool must be very careful at choosing octree "deep" and size to make it optimal : CHC algorithms tests Octree node hierarchy for visibility. So Octree Node has to be the most "full possible", a test for a small alone object would take more time than drawing it directly.

So the idea is octree node vis tests will help doing that

loadAndDdisplayOctreeNode()
{
if (CHCvisible()) // give CHC test resutls
{
for all children nodes
loadAndDdisplayOctreeNode( nextChild())
}
}

(pseudo-pseudo-pseudo code)


Before GOOF framework apparitions, I did intend to use dotSceneOctree format and make a specialized tool that outputs a per page .scene from a global world .scene or mixing many .scene.

But now, I'll wait for GOOF, help it doing that or make it doing that if needed.

Falagard

25-01-2006 16:08:55

Okay, great, sounds good.

You really shouldn't have to wait much longer (weeks not months) for an initial release of GOOF. It won't have everything in the world, but it will be good enough to show off the CHC in action since I'm going to be adding the "occluder" and "occludee" flags to the mesh objects and then simply name the nodes and entities accordingly.

Eventually I'll be adding your impostor code for kinda far things like trees, and implementing vertex program oriented billboards for really far trees. As you can tell, trees is where I see impostors being used the most ;-)

What I'm going to release in a couple weeks WON'T have the following features:

Undo/Redo
Copy/Paste
Visibility show/hide objects
Object selection/scene graph display (such as a treeview of all objects in the current partition)
3ds Max style movement/rotation axis controls

Those are nice to have, of course, but I'm out of time and want to get it out for people to look at ASAP.

jacmoe

25-01-2006 23:39:10

@Falagard & tuan kuranes:
This is absolutely great news - to put it mildly! :D

It means that we soon can realise a world where transitions between indoor and outdoor doesn't exsist!
Where you can actually have windows in your interiors, ..
This is quite something! :)

Soon we will make games like Oblivion ... 8)

Falagard

25-01-2006 23:59:55

Actually, Oblivion doesn't have seamless interior to exterior transitions (there are loading screens same as morrowind), and you can't see outside from the windows ;-)

jacmoe

26-01-2006 01:36:05

I know! :D

Jerky

26-01-2006 07:54:52

This is just awesome news. Falagard and I were just discussing this last week. You guys are awesome. These type of things are really going to help Ogre make its mark. Keep it up!

Falagard

27-01-2006 19:27:08

Okay, so I've finished the following:

1. The application framework. Includes state management for different screens. An InterfaceManager class sets up the GUI and manages InterfaceScreens. There is one active InterfaceScreen at all times, and one InputController. These two classes receive mouse, keyboard and frame updates, with the active InterfaceScreen receiving messages first, and then the InputController. An example of an InputController would be a free camera controller that allows free movement through a scene. An example of an InterfaceScreen would be a start screen, options screen, and the main game. In the case of the Editor, the whole editor interface exists in an InterfaceScreen.

2. A common libary that includes abstract base classes that allow communication between systems. The InputController base class, the sample FreeCamControllerImplementation, and the EditorSystemContainer base classes exist here. The container class is used when the editor needs to communicate with whatever it is that is holding it. This way the editor can be embedded in any application implements the container class (you don't NEED to use MY application framework at all, you can embed it your game as long as you inherit from this simple class).

3. EditorSystem - all the editor functionality is in this library. Base classes for plugins, tools, and operations (for undo/redo eventually) are here. Initializes the gui for the editor, allows switching between plugins, tools, etc.

A plugin is a collection of tools and functionality. For example, there will be two or more tools for managing terrain, one is for modifying the terrain height, and the other is for painting textures on the terrain. Both of these will be managed by a single plugin.

When a tool is chosen from the GUI, it activates its plugin. The plugin is an input listener and receives all subsequent mouse, keyboard and frame events. The plugin, when activated, checks the current scene manager is the one it expects. If not, it activates its scenemanager. This means that you can be editing multiple different scenes at once if you wish, with one tool working the PagingLandscapeSceneManager, and another working with the BSPSceneManager.

4. EditorApplication - uses the ApplicationFramework, the EditorSystemContainer, and the EditorSystem together to create a standalone editor.

That's it. Here's my remaining todo - it's a long list, but a lot of it is just moving existing code around into new classes so that the game object framework can work with any scene manager, not just the PLM2.


Todo:
Move save and load out of pagingmanager to coremanager
Move enumerateobjects and enumerate categories to coremanager
Link and unlink to core
StartSimulation to core
savePrefab to core
Modify getheighat to do a raycast down
Cameraorietnationmanage, sound and backgrounddependencymanager should be registered as systems that receive update()
Generic collision detection should be implemented at core with an abstracted collision manager
Actor 3rd person movement should be handled externally by the ObjectManagerPlugin
Enumerate nearby objects should be at core
Collision detect should in generic manager - so we need a CollisionSystem and a CollisionManager or something, where CollisionManager CollisionSystem is capable of performing collisionentity to collisionentity collisions
We need to abstract collision entity
Page should be Parititon
Move Save from page to partition
Load
AddObject
RemoveObject
StartSim
EndSim
Destroy
Update() in Page needs to be looked at and see if we can move it to partitionmanager or something
Keep in mind Page versus Interior partitions and how they'll work
Partition::Update current does things like convert objects to static geom, etc. See if that should still be the case.
All the lod changing stuff is going on in Page - I think it should still however we need to look at it.

Create the following two classes:

PartitionManager
update()
getPartition(Vector3 position)
rayCat
Partition
getID()
addObject()
removeObject()
startSimulation()
endSimulation()

Create simple single partition implementation of PartitionManager that can be used for any scene manager.

Create PLM2PartitionManager and PLM2Partition to work specifically with the PLM2 system (already done, just need to move code around).

Create GameObjectFactory class for instantiating objects
Create MetadataFactory class for instantiating metadata

Add GameObjectManager->registerObjectFactory
Add MetadataManager->registerMedataFactory

Falagard

27-01-2006 19:36:35

By the way, I'm very excited the plugin and tool system, and the fact that each plugin can create it's own scene manager.

This means that other tools can integrate directly into the editor. Example, the Particle Editor that you guys may have seen can be implemented as a plugin directly into the editor. The TreeMesh generator that uses the same code as Arbaro can be put into the editor directly. Game specific tools can be put in. Etc.

jacmoe

28-01-2006 01:49:12

Great news! :D

Would it be possible to - say - write an entity plugin which adds entity properties, maybe adding a property page/tab, makes it possible to attach scripts, etc. ?
IE game specific stuff? :)

You are killing me - I can't wait to lay my grubby pawns on it all! :mrgreen:

Falagard

28-01-2006 01:56:13

Can you describe that further?

I already have a "Object Properties" window that queries the selected game object for it's property list and dynamically generates a form that lets you modify the properties of the game object. That's been in there since March or April of 2005:

OLD VERSION OF MAP EDITOR FROM APRIL 2005:
http://www.larabie.net/ogre/MapEditorPreview.jpg

That shows a test object that exposed properties for name, orientation, position, bool property, int property, string property, etc.

You can tell it's old since it used the TaharezLook instead of the newer WindowsLook GUI.

But to answer your question, you can add anything you want basically, and it doesn't have to be anything to do with Game Objects, such as my examples of putting in the Particle System editor or the Tree mesh generator, which are not using the Game Object system at all, but could still be plugins into the GOOF editor.

jacmoe

28-01-2006 04:37:19

No, I am talking about game specific attributes: like enchantment, armour points, spells, etc.
But that's probably covered. :wink:

Looking forward to seeing it. :)

Falagard

28-01-2006 05:06:48

Yes, you could use the existing object properties window to do that, or alternatively, create your own plugin if the properties dialog is too generic.

Example:

Let's say you have JacmoeNPC which derives from GameObject. You could add new game specific properties to your JacmoeNPC and expose them through the enumerateProperties function which is a virtual function on GameObject. If you insert a JacmoeNPC into the scene, the editor would display those properties when the user clicked "Properties" on the object. The user would then be able to edit those properties

Alternatively, you could create a new EditorPlugin that had a completely custom interface screen for editing the properties of your NPC, or do whatever you want. If for example, you have a database of spells, weapons, etc. and want an interface to editing those spells effects, values, etc. you could do that as a plugin.

jacmoe

28-01-2006 06:34:53

What can I say? :wink:

You have it covered - very obvious that you are putting a lot of thought and effort into what you do. Kudos! :)

Rendar

31-01-2006 18:03:33

Jacmoe... on that subject about the seamless transitions...

I'm currently playing World Of Warcraft and I've been studying some of the interesting things I see in their game world and try to apply it to what I know about programming. All of their dungeons use instancing, i.e. you step into a portal and it teleports you and your group to a unique version of the dungeon.

It is possible, however, to sometimes get through the portal without teleporting and on the few occasions its happened to me I've run around looking at the differences... in most cases there is an exact duplicate of the dungeon but it just ends at some point or there is a wall where there should be a door (basically, as far as the viewable area goes from where the portal is, and therefore the intended limit to the view of the player, the dungeon looks just like the instanced dungeon).

Now, there are some dungeons that are castles that do indeed have windows in them. In these cases, you can look out and once again can see the game world no problem but you never see players or anything running around outside. My theory on this is, like what they do with the dungeon interiors for the "real" game world, they have a piece of the terrain that is rendered for the viewable player distance from the window and that piece of terrain is actually part of the instance and therfore will not render players and creatures currently in the "real" game world. You can, of course, jump out these windows, zone into the real world, and continue falling :) .

Anyways what I was getting at are that there are several games out there that have accomplished some VERY nicely done seamless transitions from outdoor to indoor as far as the art and such is concerned. While, technically, since you "zone" in and out to unique instances in WoW I guess thats not exact seamless since there is a loading screen BUT, as I said, at least parts of the dungeons are there in the game world and if they hadn't done the instances idea then I have no doubt the entire dungeons would have just existed in the game world and you would have some very nice seemless dungeons.

I realize this is slightly off topic but I thought I'd post that anyways and see what you had in mind for the exporter :)

Rendar

p.s. Long time no see Falagard...not since the Auran forums :) I've been lurking on here eagerily awaiting this and the 3DSMax Exporter being worked on as well.

Falagard

01-02-2006 02:38:28

Hi Rendar, I recognize you :-)

Good points about WOW. I've looked at WOW using GLIntercept - if you're interested in that sort of thing I suggest you do the same.

http://glintercept.nutty.org/

GLIntercept was created by Damian Trebilco, (Sqrt-1 on the Jet forums)

You can get free control of the camera, turn on wireframe, etc. and capture textures and shaders. Anyhow, you can see some of the tricks they're doing - nothing really crazy though.

Regarding the instance dungeons and zoning, yeah that's probably what I would do. Create boundary areas that zone a player into the instance and back out... and yet use the same client data either way, but without seeing other players in the surrounding terrain.

Falagard

02-02-2006 22:32:44

Update:

Still powering through that todo list. As I said, it's mostly refactoring existing code, however I also have to think about the overall design as I'm doing it.

On average, working 3 hrs a day on it.

I added a DataFile and DataElement wrapper over TinyXML so eventually we can save/load to binary or xml (binary when distributing for speed).
Added SceneManagerWrapper class to wrap the scene manager for specific calls that may be different between scene managers. Currently only function is executeRaySceneQuery().
Created the GameObjectFactory class and code to deal with those.

I now have CoreGameObjectManager, PartitionManager, Partition complete.
Next I have to finish CoreGameObject. Then go through and make tweaks to all the implemented game objecs (MeshGameObject, etc.).

I expect about another week of work to finish the changes, then perhaps a week to do some testing and tweaks and integrate with Dagon and latest PLM2.

Clay

OvermindDL1

02-02-2006 23:35:46

Sounds like it is coming along quite well. Cannot wait to test.

Falagard

03-02-2006 01:49:04

Hehe. Well, just to make sure everyone is aware, there isn't going to be a spectacular demo to show this thing off. In fact, it may look pretty crappy initially. It'll all be about looking at the code and seeing what's going on, and getting a feel for what it will become.

OvermindDL1

03-02-2006 04:49:29

Bah, I rarely pay attention to the glitter of stuff, I like to see how it works.

Falagard

04-02-2006 16:43:38

Update:

Still powering through. I've completed the updated CoreGameObject functionality. The last two days I've also sat down to figure out the following:

How can I have a partition system (partitions are responsible for loading and unloading objects and settings lods on objects) that will be generic enough to work for most games? A system that developers can use out of the box with a couple sample partition managers (the manager controls the loading and unloading of partitions... while the partitions control the loading and unloading of objects) such as a grid partition manager that works for things like exteriors and terrains based on a grid, and an interior partition manager that has a list of connected rooms and loads and unloads room partitions based on which room you're currently in, and what rooms it is connected to. How about when you want to mix the two, so you have grid and interior partitions mixed together.

And I KNOW I've worked out a great design for it.

Check it out:

I've taken the idea of PartitionManager and renamed it PartitionLoader. Now there's a single PartitionManager that has a list of PartitionLoaders. There'll be a GridPartitionLoader and an InteriorPartitionLoader, for example.


PartitionLoaderManager - this class basically just managers partition loaders.

addPartitionLoader(PartitionLoader* loader); - adds a partition loader to its list of loaders

getPartitionLoader(const String& name); - retrieves a loader by name

getPartitionByPoint(const Vector3& point); - gets a partition by a world point. This is called by the GameObjectManager as the user drags an object around the world in order to find out what partition it's in. It's also used to determine which partition the camera is currently in. This function iterates through all PartitionLoaders and calls a similary named function, enumeratePartitionsByPoint which returns a list that may contain multiple partitions. It goes through this list after query every loader, and if any partitions return ResultYesMustUseThisPartition then it uses that partition. If multiple return just ResultYes, then it picks the first one returned.

update() - this function calls update() on all PartitionLoaders

The PartitionLoader class - this class loads and unloads partitions

enumeratePartitionsByPoint(vector<PartitionQueryResult>& results, const Vector3& point); this function calls each partition's queryIsPointInPartition(Vector3 point) which then returns an enum that has values like ResultYes, ResultYesMustUseThisPartition, and ResultNo.

update() - calls update on all partitions it manages

The Partition class is exactly like my existing partition class, it has load and save methods, updates lods, etc. No real changes here.



Okay, so WTF is with all these functions, and why is it so complex? It's only as complex as it needs to be.

Here's the deal:

A GridPartitionLoader will be initialized with number of cells, and will create a partition for each cell. It'll then control loading and unloading cells based on camera position, similar but separate from how the PLM2 manages pages. This will allow it to be used with any scene manager, including Ogre's built in TerrainSceneManager. There may or may not be a need to create a GridPartition - it may be possible to use the built in Partition.

An InteriorPartitionLoader will work with linked rooms. The rooms will probably be convex hulls, so that I can detect whether a point is inside a room. Each room links to a set of other rooms that are potentially visible from this room. Rooms will only be loaded if they are linked to the room the camera is currently in. This allows for huge dungeons, hotels, even apartment buildings with hundreds of rooms. InteriorPartition will maintain a list of linked InteriorPartitions (rooms).

SinglePartitionLoader - a sample loader that just loads a single partition. This is useful if you don't need fancy partitions! Just a single world that saves and loads.

And the kicker:

InteriorPartitionGameObject - this will be a placeable object like all other objects, and will have a mesh that represents a room's boundaries. It'll be placed in the world via the editor. The InteriorPartitionGameObject will have standard properties (editable in the editor) that allow it to link to other InteriorPartitionGameObjects. This lets you build your rooms in the editor itself. These objects will exist inside another partition, such as a grid partition. When created, they'll actually create a corresponding InteriorPartition and add it to the InteriorPartitionLoader.

As you drag an object around in the editor, it checks which partition the object is in using the world position of the object. An object dragged inside the boundaries of an InteriorPartition will actually be in two partitions at once - it's inside a grid partition and inside the interior partition. That's why the enumeratePartitionsByPoint returns a ResultYesMustUseThisPartition. The grid partition will just return ResultYes, but the InteriorPartition will return ResultYesMustUseThisPartition.

Which reminds me, it shouldn't be possible to place a InteriorPartitionGameObject inside an InteriorPartition so I'll need some way to stop that from happening. Such as a Partition->supportsObject(object) which happens before asking if a point is inside the partition.

Anyhow, this should be very cool once I get it working. Also, it'll be generic so you can add your own types of PartitionLoaders and Partitions if the built in ones don't cut it for you.

Question: Does the InteriorPartition replace portals?
Answer: No, not really. It's more like a way to dynamically load and unload objects based on where they are in an interior. One InteriorPartition may span a huge area, if you wish. Or it could be as small as a single room. If it is a single room, and you link it to only the rooms that are potentially visible from this room, then it will unload InteriorPartitions that are not linked. More likely it'll be used inside a scene manager that has portal support, or occlusion culling. The PLM2 does have occlusion culling, for example. It could also be used inside a BSP scene manager.

Clay

jacmoe

04-02-2006 18:54:37

This sounds amazing! :)
It would probably be possible to tie into this framework for things like sound and physics.
I just wonder how this is going to work in the standard terrain sm: there is a limit to how big a single map can be..
But the general idea is very appealing. :wink:

Falagard

04-02-2006 19:09:05

There's nothing wrong with partitioning objects that are even on a small sized terrain into a grid. Let's say you have a 1024x1024 meter (roughly a kilometer) terrain being managed by the TerrainSceneManager. You can split it up into a 4 x 4 grid, with a partition every 256 meters. The partitioning not only manages loading and saving, but also with things like LODs, static geometry, and updates.

So your 1024x1024 terrain is for a multiplayer map. If you're on one side of the terrain, too far to see a water fountain particle system and hear its water spraying sound on the other side of the map, the LOD system will ensure that the sound isn't playing and the particle system isn't spraying. The resources for those objects also won't be loaded and taking up memory.

Borundin

04-02-2006 20:25:12

First of all, I would like to say that this thread is one of my favourites in all of the Ogre forums :o . Always intresting to hear your reasoning and see the progress of GOOF and the editor.

About your PartionManager, PartionLoader and Partition class. In my own project I have come up with a similar solution, although not as generic and well thought out as yours. But then again it is not meant to be a generic framework. It really is necessary when having a large complex world to partition it in a logical manner, be it grid or linked or some other way. I was thinking also in a network based game that those partitions could be useful on the server when deciding what information to send to what client? Maybe there has to be other bounds (ie smaller partitions) than on the client, but the same classes would still be useful.

Anyway good to hear about your progress. Keep it up!

Falagard

06-02-2006 04:20:18

Thanks Borundin.

Yeah, I'm always keeping two things in mind: 1) I'm doing this for a real game, so it has to work for me. 2) Others may want to use it, so what things can I change in the design to accomodate others.

Most of the things I do are fairly minor changes, but make the whole thing more flexible.

I've been thinking a lot lately about the networking side of things and how it's going to work with GOOF. If I have a standalone server, let's say for an MMO, I want it to be running GOOF as well, with Ogre initialized but not rendering. As far as partitioning objects on the server, I can definitely see this being used on the server for an MMO. Basically, as players (or any server controlled object in general) move around they'd automatically move from partition to partition based on their location. One of the big parts of an MMO is object discovery - that is when the server needs to send down information about things around you as you walk around, and that would be made much easier by having a grid or cell based partitioned world.

I don't want to sidetrack too much, but ReplicaNet is an amazing library - at least from the architecture side. I haven't actually even played with it yet, but if it works like it says it works, there's just no other networking library out there that can handle an MMO as well as it can.

jacmoe

06-02-2006 06:28:34

I hope you will be releasing GOOF before it contains everything but the kitchen sink! :P

I can't wait! :)

Falagard

06-02-2006 06:56:25

Ya, I'm trying to just get it out there and then update it with features as I go.

Falagard

12-02-2006 07:45:12

I wrote another super long and boring post on the main forums and have copied it here because it's relevant.

I'll tell you a story about an imaginary product. The product had roughly 40 different types of objects with different behaviors. The system we used was to define a base class (for example, GameObject) that our objects inherited from that all objects that would end up in the 3d world would share. It ended up being a large class, but most of the functions were used by all derived classes. The biggest complaint was that this class was large and it was evident that there were functions had something in common. An example would handling movement - there might have been functions like canMoveTo(position), moveTo(position) which in turn might have called upon collision functions to perform sweep tests, or whatever. The collision functions were also common, such as collide(ray) and collide(object). The canMoveTo might have been calling collide to test whether it could move to the position.

After the product was done and we had to work on the next version, we looked at the architecture and wanted to do something about this monolithic class. Many possibilities came to mind. A few included:
1. Break out the common functionality into interfaces and have the GameObject use multipleInheritance
2. Break out the functionality into behavior classes. The GameObject would be an object that simply represented itself in the scene, and stored state. The behavior class would be external to the GameObject, but each instance of a behavior class would act on a single GameObject.
3. Same as #2, but use containment and aggregation and have the GameObject contain the Behavior classes and expose the functions of the Behavior class as if it were its own (perhaps using messages instead - so the GameObject could receive a message and if it doesn't handle it directly, pass it down to a behavior which might know what to do with it).

What option did the imaginary product choose? I can't tell you that, trade secrets. Actually the original architecture was flexible enough that we didn't have to make sweeping changes to the system, but it is somewhere between 2 and 3, and the modifications can be done on individual areas where it seems appropriate.

You may or may not know I'm working on a game engine / game framework for Ogre called GOOF, which means I'm doing another archicture that again deals with objects and messages. This is my third application that uses an OO architecture, and what am I doing this time you might ask? This time I'm dealing with networking, and so I've gon with approach #4

4. A combination of inheritance, contained behaviors and externally acting behaviors.

What the hell does that mean?

I need to have a physical object in the scene that has a mesh, and walks around, playing an animation based on walk speed. I need to perform collision detection and possibly pathfinding. I need the player to be able to control this physical object directly sometimes via mouse and keyboard, and sometimes NPCs with control it using AI. Networking may be involved, such that it is being controlled remotely by a server, either by a player directly or by AI. And it needs to be a clean architecture. There are so many ways to do this it boggles the mind. Is there a clear best way? Maybe. Personally I think it's a matter of taste.

Here's what I'm doing:

GameObject base class which represents physical objects in the scene. Doesn't know anything about meshes, but has position and orientation in the world. Does have collision functions, if derived classes call setCollisionShape() to set a collision shape, then rayCollide(ray) and objectCollide(object) can be used. Doesn't detect collisions automatically, just has low level collision functions.
MeshGameObject inherits from GameObject, loads a mesh, and can play animations.
ActorGameObject contains a MeshGameObject as a member variable. Here's where ActorGameObject could have derived from MeshGameObject instead, but I used containment. Another decision was made here to have the ActorGameObject actually handle its own movement, having moveForward, moveLeft, moveBackward, moveRight, and look functions for direct movement from mouse and keybaord, as well as moveTo which will perform pathfinding for NPCs. The direct movement functions actually just change the velocity and angularVelocity. All GameObjects can receive per frame update() calls, and ActorGameObject uses velocity and performs collision detection by asking the GameObjectManager for nearby objects and then testing collisions using the objectCollide() function.

Eventually there'll be an AISystem which manages AIAgents. AIAgents represent an intelligent creature. Each AIAgent will have its own state machine that identifies its states and what causes a transition between states. Anyhow, the AIAgent may act upon an ActorGameObject. In this case, the AIAgent is not a GameObject, it just has a pointer to a game object and acts on it externally.

Here's a different requirement that will use messages:

I need to be able to click on an object in the scene and display a list of possible interactions to the user via the UI. The user can pick an interaction from the UI, (such as Open, Close, Pick Up, etc.) and then the action happens.

Imagine a door that is currently closed. Player should be able to click on the object a menu pops up with the option "open". User clicks on "Open" and the door opens.

What is actually happening:

GameObject has function called enumerateInteractions.
DoorGameObject inherits from GameObject, contains a MeshGameObject, and exists in the scene.
UI asks the object for list of possible interactions via a function enumerateInteractions, DoorGameObject checks its current state, which is closed, and returns "Open".
UI displays "Open" to the user.
The user chooses "open" via the user interface.
The UI posts a message to the GameObjectManager, which handles all GameObjects in the scene. GameObjectManager->postMessageToObject(object, AttemptToPerformActionMessage("Open")).
The GameObjectManager sends DoorGameObject the message through handleMessage(msg).
The DoorGameObject checks the message type, and calls attemptAction("open") which checks its state again to see if it is still closed, and if so, it calls GameObjectManager->postMessageToObject(object, PerformActionMessage("Open") which is actually posting the message back to itself. (You'll see why).
Exception: If not still closed for some reason, calls GameObjectManager->postMessage(PerformActionFailedMessage(object, "open")) - which uses publish/subscribe so that anything that has subscribed to PerformActionFailedMessage will receive the message. The UI will have subscribed to and will display a message to the user "could not open".
If everything went well and the DoorGameObject can close, the DoorGameObject will receive a PerformActionMessage to handleMessage(msg), which it will then set its state to open and then call its contained MeshGameObject->playAnimation("Open"). Or maybe the playAnimation will also be sent as a message.

Now, adding a simple change to this system we can make it viable for networking. This is a assuming we're using a replicated/duplicated/proxy-ish networking system like ReplicaNet, Quazal Net-Z, or Raknet.

Add a class called DoorStateObject and make the DoorGameObject slightly more dumb, in that it doesn't know its own state (open or closed), but instead asks the DoorStateObject if it is open or closed. If DoorStateObject->getClosed() returns true, it calls DoorStateObject->attemptAction("open"). If the DoorGameState is not the master object (it is a proxy to a network object running on the server) the DoorStateObject->attemptAction() call is a remote procedure call called asynchronously against the server. The remotely running object gets attemptAction() called on it on the server. The DoorStateObject on the server runs exactly the same check as before, are we still closed. Instead of calling GameObjectManager->postMessage it has a proxy network object back to the client(s), so instead of calling GameObjectManager->postMessageToObject it calls client->postMessageToObject which will be called asynchronously. The game client will get the call, which will forward it on to the GameObjectManager.

In fact, the network system I'm planning to use is more flexible than that, because the exact same code is used on the client and server. The client(s) have a proxy to a remote object on the server and can call an something like doorStateObject->attemptAction("open") which will RPC to the server, and then the server can call doorStateObject->performAction("open") which will call that function on each client that owns a replica. The doorStateObject proxy running on the client will obviously call GameObjectManager->postMessageToObject(DoorGameObject, PerformActionMessage("open"));

Of course, these RPCs are actually sending messages back and forth as well, but that's managed by the underlying networking class.

Clay

tuan kuranes

12-02-2006 08:14:53

Could you elaborate on parallelism approaches ?
I mean, at least Network Client, Network server, Input, Game logic, AI, Phys need to be into differents threads.

Ie: A good approach is Triple Buffering, which gives "Critical Section" minimisation + Interpolation bewteen previous and new State. Which means special care about handling data to be in those buffers (size...)

Falagard

12-02-2006 14:24:48

I'm not an expert on multi-threading, however in our product we had to post messages from background threads to the main thread. In that case we had a ThreadSafeMessageQueue class which handled locking and unlocking to add and remove messages from the queue.

Messages would be posted to the ThreadSafeMessageQueue into a list of queued messages, and then in the main thread's update() call it would go through the messages and handle them.

Of course, in my case the background threads always sent messages to the main thread, but you're asking about message posting across threads.

Back in the main forums I posted about a MessageReceiver class. I'd think that the best way would either be to have each MessageReceiver have the equivalent of a ThreadSafeMessageQueue and then have an update() function called from that instance's native thread which would then handle the queued messages, or alternatively, (and better in my opinion), each thread has a message dispatcher.

So it would go something like this:


class MessageReceiver
{
public:
MessageReceiver(MessageDispatcher* dispatcher);

handleMessage(Message* msg)
{
dispatcher->queueMessage(this, msg);
}

handleMessageSafe(Message* msg);
}


Every thread has a MessageDispatcher. Every MessageReceiver registers itself with the MessageSystem on the main thread. Anyone wanting to send a message calls MessageSystem->postMessage which has a ThreadSafeMessageQueue that safely maintains a list of messages. The MessageSystem posts messages to MessageReceivers on the main thread. the MessageReceivers receive the message pass it to the dispatcher so it will get posted to them safely on their own thread during their thread's main update() using handleMessageSafe.

Or something like that?

Can you elaborate on Triple buffering and what you might do to solve the problem?

tuan kuranes

13-02-2006 08:11:40

Can you elaborate on Triple buffering and what you might do to solve the problem?

thread 1 : world update generates a view [depending of thread, it may be AI state, Input State, Physic State, Network State, MessagesQueue State] of the world into one buffer (A).

thread 2 : A is immediately copied filling the next buffer (B).

thread 3 : it looks for the last completed view and finds (B) which is a copy of (A), which it starts using/computing on immediately.

Note that Thread 3 process may return data into Thread 2, using same mechanism, Thread 2 would be copying Result Buffer (Aprime) to (Bprime), which then would be read by Thread 1. (Depending on when Thread A needs Data, you can even use another ("The Intermediary Thread"), named Thread 4 in order to asynchronously get restults.

So on each Dataset we have 3 buffers A, B, C. Purpose is to avoid Real Thread (A, B) to lock themself each other, resulting in a nearly null critical section.

Falagard

13-02-2006 16:11:02

Very cool. I can easily see using that for physics. However, I would prefer if the physics library itself handled the multi-threaded transparently. An example is Novodex - I have read it is multithreaded.

Same goes with the networking library - it should be handling communication via its own thread(s).

tuan kuranes

13-02-2006 17:29:32

AI, Sound and fast simple collusion are good "threadable"spot too.

Falagard

13-02-2006 18:50:04

Wow, you're pretty gung-ho on multi-threading. I think it adds too much complexity and you should only put the things you HAVE to on another thread.

AI I would break the processing up into steps across frames if it was too CPU intensive.

Sound should be handled by the sound library, if it needs to run on a separate thread it should be transparent and automatic.

Things I would do on a separate thread:
Background resource loading (handled by requesting a resource and setting up a callback for when the resource is finished)
Physics (handled by the physics library transparently)
Networking (handled by the networking library transparently)

tuan kuranes

14-02-2006 07:56:29

Things I would do on a separate thread : sound, network
That today "classical" threading, Will it be still be possible in "nextgen" mutli-core world ?

Wow, you're pretty gung-ho on multi-threading.

We should all be for our future...
From good analysis article Managing Concurrency: Latent Futures, Parallel Lives About Next-Gen, Multicore and their generalization, sort of follow up to another mst-read article, The Free Lunch Is Over from Herb Sutter.

Xbox 720 should have 24 cores, each running two hardware thread
Ouch. Game, Physic, Sound, Network. That's 4. You'll still have 20 cores waiting for us to send some code to execute...

I think it adds too much complexity and you should only put the things you HAVE to on another thread.
On the contrary, I think it helps better design, as it enforce clean, definitive separation on different parts of the application.

AI I would break the processing up into steps across frames if it was too CPU intensive.
Ai is a large term. Pathfinding, visibility updates, flocking, Task Evaluation, Task Queuing, Task Execution are threadable... And many of those have enough granularity to helps controls hox much CPU power it will takes.
Even more, AI results can be partial and still be used, and results doesn't always have to be synchronous (it just have to be not too slow "visually")

Falagard

14-02-2006 16:53:47

I mostly agree that creating an architecture with multi-threading in mind is good future proofing. However, I still want the architecture to be simple and not to over-design it.

*I've edited this whole message*

I can live with buffering object state, as long as we're agreeing that the state is readonly. So, for example - if Physics are running on thread A, the physics objects current positions and orientations are the state we want to share with another thread, thread B. Thread B can access this data via a buffer, but cannot change the values in the buffer, instead if thread B wants to communicate with objects on Thread A, it sends a message.

Each thread has a message dispatcher, which has a list of messages that should be sent next update, and a list of messages that were received since the last update.

Thread B can send messages to objects on Thread A. Instead of the messages being sent immediately, they are added to a list of messages that to send next update in the dispatcher on Thread B. Then during the next update, all those messages are sent to Thread A at the same time. Buffering *could* be used for messages, as well as state objects.

Thread A's next update checks its received queue and dispatches the messages to the objects on its thread.

So the way I see it, object state, and messages, could be triple buffered.

Clay

tuan kuranes

15-02-2006 10:09:17

not to over-design it

Couldn't agree more. Threading can slow developpment times a lot.
Best would be to describe clearly and totally the triple bufferring into some easy and strong design pattern.

Perhaps I should demo it some way... along with with benchmark programm to show improvement...

state is readonly ... if thread B wants to communicate with objects on Thread A, it sends a message.
Totally agree. And states are just "states", not object serialisation or object save at a state. Great Care must be taken to choose how to define a state, and how to minimize state size.

Buffering *could* be used for messages, as well as state objects.
Thread A's next update checks its received queue and dispatches the messages to the objects on its thread.
So the way I see it, object state, and messages, could be triple buffered.

*could* as not mandatory, message being flagged at 'Instant' or 'Asynchonous' ? Seems ok and necessary to me to have both...

Falagard

15-02-2006 15:21:59

Right, you'd want some to happen instantly and synchronously, but be aware that there's a performance penalty.

Ya, I wouldn't serialize state, just copy it.

I think the best bet would be to define a state class, and have a state manager on each thread. The state managers would copy state between threads. You'd "register" a state object (instance of a class that derives from state class) with your thread's state manager, and it would automatically get copied to other thread's state manager each frame. Each thread's state manager will have a copy of the state of all state objects on all threads, or maybe objects could be put into groups in their owning state manager and then state managers in different threads could be set up to copy only certain groups to other state managers.

Example of main Thread A performing rendering and physics running on Thread B using state classes:

Thread B is running physics and for each body there's a corresponding PhysicsState instance that is registered with Thread B's StateManager. PhysicsState has 3 values, position, orientation and velocity. The physics simulation updates PhysicsState instances each update loop in Thread B. The StateManager on Thread B copies all state objects to Thread A's StateManager at the end of Thread B's update loop using buffering, or locking, or whatever.

Thread A will have a SceneNode with an Entity attached for each physics body, and will poll the position and orientation of PhysicsState objects in the StateManager each frame, updating the position and orientation of a SceneNode based on the current position and orientation of a PhysicsState object. Of course it could be handled nicely if you have a class like MeshGameObject which receives an update() call each frame and can have a pointer to its corresponding PhysicsState object.

Which reminds me that you should be able to keep pointers to the State objects, so the copying that occurs between state managers should find existing objects and do a copy of values, so each state object needs a unique ID. If existing object doesn't exist, then a new one is created and added. Another trick is that if a state object was deleted on the other thread, it should get removed from state managers in other threads, but this needs to be handled nicely so that objects that have a pointer to a state object can know it was deleted. I'm open to suggestions.

Anyhow, does this look like what you might be expecting?

Clay

Falagard

16-02-2006 00:52:01

Progress Update:


Linking...
MapEditor - 0 error(s), 30 warning(s)


Whew. It's been a while since I've seen that.

Falagard

16-02-2006 06:14:48

Well, good progress last couple days. After 2 weeks of work every night for a couple hours and not compiling the whole project because of all the refactoring I've been doing, I finally compiled the project and got all the compile errors out. Then I sat down for a couple hours and worked through the runtime bugs and now have the a simple editor again, using the new partition system. I created a simple "SinglePartitionManager" to ensure that I could create objects, and dropped in a MeshGameObject. Woot.

Despite what it sounds like, this is really good - it means the systems are in place. I still have a lot of work to do, but it's good to see a running app again.

OvermindDL1

16-02-2006 07:53:41

Sounds like it is coming along well, will it be anon cvs soon so we can test?

Falagard

16-02-2006 12:47:44

It'll be available when I'm happy with it going out.

I'll be available as a binary first, then as a .zip download second, and in CVS last.

tuan kuranes

16-02-2006 14:55:05

Problem is that when object state doesn't change we still call StateUser "update()" each frame.

Let's call Physic Object / Entity / AI agent StateUser. Each StateUser from the same global overall agent "Object" has a Unique ID.

StateUser emits as a result of its own computation 1 State per frame/step.
StateUser keeps a list of last n states corresponding to last n frames/step. (useful for many others reasons, like interpolation, state machine history, etc..?)
StateUser registers new states in the statemanager. (with a ID shared by all related StateUser)

Statemanager A handles the copy to the other thread and clear() its state list afterwards. StateManager B handle data til StateManager C can reads from It and call Entity (using ID as find criter) to update it.

StateUser would delete its state upon a max frame/step history Global variable. (could be 1 if you're not using interpolation)

Falagard

16-02-2006 15:48:29

Okay, so you're saying that the StateUser will emit a new State, and the StateManager only copies states that have changed to another thread since the last frame.

Just to double check - are you saying that objects will register themselves as interested in a certain StateUser's state changes, and they receive events when the state changes? Yeah, that sounds fine to me.

I'd like to try to do a proof of concept on this using a physics engine and GOOF.

Clay

tuan kuranes

16-02-2006 17:06:40

StateManager only copies states that have changed to another thread since the last frame.

StateUser will emit in StateManager a new State only if (State != LastState)
As a result, StateManager only copies states that have changed to another thread since the last frame

objects will register themselves as interested in a certain StateUser's state changes, and they receive events when the state changes?
StateUser registers their States, flagged with an ID that StateManager in the "receiver" Thread use to determine to which StateUser that State should be sent to.

Falagard

16-02-2006 17:32:56


StateUser registers their States, flagged with an ID that StateManager in the "receiver" Thread use to determine to which StateUser that State should be sent to.


I don't get it.

tuan kuranes

16-02-2006 18:10:41

I'll try to explain myself better using an exemple:

in a racing game you have a vehicle represented by a GraphicEntity and a PhysicObject, both being StateUser and running in different threads, but sharing a same Unique ID.

PhysicObject compute it physics and save results in a new RigidBody class, that inherites from State. This State Object pointer is registered in PhysicObjet Statehistory and its thread StateManager A.
... times pass...
thread StateManager A copies into B all its states and clear its list.
...
thread StateManager B copies into C all its states and clear its list.
...
StateManager C iterate over each state, reading its ID, calling each StateUser corresponding and call update(newState).
Entity receive then the new state, which is a new RigidBody class instance.

PhysicObject may be not register a State into the StateManager upon a Frame (when sleeping) and then Entity Update(NewState) won't be called.
In a Scene with a lot of sleeping Physic Object, that means a big Save.

Entity can Filter the new State, and decide to apply or not. (in case of networked physic game it may have to choose between physic state and network state.)

Falagard

16-02-2006 19:56:04


Entity receive then the new state, which is a new RigidBody class instance.


This is the part I don't understand. Why does EntityObject receive state from the PhysicsObject, has it registered itself as a subscriber saying that it's interested in state from PhysicsObject with a particular ID?

That's where I'm getting lost.

tuan kuranes

17-02-2006 07:56:36

Entity and PhysicObject reresenting a same game content share the same ID, given at creation.

Something like

addCar()
{
ID = getNewUniqueID()
new physcic(ID)
new Entity(ID)
new AIagent(ID)
...
}

Falagard

17-02-2006 13:52:32

Yuck, don't like that. There should be a clear "owner" of the state that is allowed to update it, while others are just observers or listeners to that state.

In the case of Physics and Network, where they could have conflicting states, there should still be a PhysicsState and NetworkState object each with its own ID, and the Entity class should have to subscribe to those two to receive updates.

Clay

antoinedb2

17-02-2006 14:17:23

Or the StateManagers appends to the state the state source :
The Entity would subscribe to EntityStateManager with its ID, telling it's interested in Physical and Network updates, and would potentionally receive two events : update(FromPhysicalManager) and update(FromNetworkManager).

Meanwhile the three stateManagers update themselves from oneother and call the update from their listeners. Using the IDs lists, they also would need to update only the states for which they have a "customer" ...

tuan kuranes

17-02-2006 14:43:42

Yuck, don't like that. There should be a clear "owner" of the state that is allowed to update it, while others are just observers or listeners to that stat

Those are stateUsers. StateUser that computes a State is the only one to be able to write on it and having pointer to it in its stateHistory list.

Well, better than english some code.

addCar()
{

ID = getNewUniqueID()
carlistphysic[k] = new physcic(ID) // : public stateUser
carlistEntity[k] = new Entity(ID) // : public stateUser
carlistAIagent[k] = new AIagent(ID) // : public stateUser
carlist[k] = new Car (physcic, Entity, AIagent, ID )
...
}


Then it emits

new physcic::compute()
{
...
HistoryStates[currframe - 1] = new PhysicState(ID, pos, orient, vel); // : public State
myStatePhysicManager->registerState (HistoryStates[currframe - 1])
}
}


here is registerState signature
StateManager::registerState (const *State);

()
Then StateManager C call appriate entities


for each ()
{
Const State *s = *i;
Entity *e = findinMap (EntityMap, s->ID)
e->updatePhysic(s);// s is const
}
}


Anyway, my point is not on a particular way.

all ways is ok to me, as long as it is following at least this rule :

"sleeping object do not sends or request update". It should be "push, not pull." to minimize "Inter Thread Transfer" and "Object loop to check for new dAta"

Moug

19-02-2006 04:37:29

Curious as to what version of Ogre you are useing?
I have the CVS Head and am getting the following errors.

C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditorListener.cpp(237): error C2039: 'getDetailLevel' : is not a member of 'Ogre::Camera'
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditorListener.cpp(237): error C2065: 'SDL_SOLID' : undeclared identifier
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditorListener.cpp(239): error C2039: 'setDetailLevel' : is not a member of 'Ogre::Camera'
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditorListener.cpp(239): error C2065: 'SDL_WIREFRAME' : undeclared identifier
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditorListener.cpp(243): error C2039: 'setDetailLevel' : is not a member of 'Ogre::Camera'
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditorListener.cpp(243): error C3861: 'SDL_SOLID': identifier not found, even with argument-dependent lookup
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditor.cpp(39): error C2664: 'CEGUI::OgreCEGUIRenderer::OgreCEGUIRenderer(Ogre::RenderWindow *,Ogre::uint8,bool,CEGUI::uint,Ogre::SceneManager *)' : cannot convert parameter 5 from 'Ogre::SceneType' to 'Ogre::SceneManager *'
C:\Ogre\ogrenew\Samples\MapEditor\src\MapEditor.cpp(79): error C2664: 'Ogre::Root::getSceneManager' : cannot convert parameter 1 from 'Ogre::SceneType' to 'const Ogre::String &'

Falagard

19-02-2006 04:52:34

The MapEditor in CVS is about a year old. I was using my own source control system using SVN, now I'm working on getting my changes back into Ogre's CVS and using it from now on.

So... to answer, the MapEditor in CVS is broken.

Falagard

20-02-2006 07:55:24

Progress update. Wow, what a week.

Implemented a simple SinglePartition sample that uses only one partition. Created a tool plugin for the new Editor framework that does all the work for managing GOOF objects. Defaults to using "OctreeSceneManager" with Ogre's cool new support for SceneManagerFactories. Now I can insert objects into a sample scene, although I don't yet have PLM2 up and running inside the editor. Of course, after all the changes I've made lately I had to wade through a lot of bugs but many are fixed now.

Added move and rotation gizmos to let you move along axis, including 2 axis at once, and rotate along an axis (similar to 3ds Max). This is in addition to the exist "drag" functionality that can drag over world geometry and other objects by casting a ray into the scene. The new gizmos, or what I'm calling Manipulators, made me create a general manipulator system for moving objects via gizmos. It's pretty nice actually, and not tied directly to objects. The gizmo calls callback functions for handleTranslate, handleRotate, and handleScale and it's up to the listener of those functions to do what it wants with those. In my case, the GameObjectEditorPlugin is the listener and moves the currently selected game objects. Also, the manipulators for translation and rotation have nice "hover over" handles that change colour as you move over them.

Updated to latest Ogre CVS head, so I'm up to date on the Ogre side of things. Had to get latest version of CEGUI from cegui.org.uk instead of using the version in Ogre head.

Complete rehaul of the old user interface for the editor. Here's a screenshot of the new work in progress user interface:



Basically, there's a tool bar across the top, and a drop down box of the available tools. As you switch tools, the tools change the toolbar buttons. In the Game Object tool, I have buttons related to inserting and manipulating objects. In the (not yet ported) Terrain Morphing tool, I'll have buttons for raising, lowering, etc. terrain. The framework is in place so that only the active plugin receives input, and when you switch between plugins the plugins will show and hide their own windows, scene manager, input controller, etc. More documentation coming later.

Also, I put in tooltips for all the buttons. (Figured out how to do that in CEGUI).

Added the ability to insert multiple objects if you hold down shift while clicking the mouse button.

Added code to check if an edit box currently has keyfocus and if so, set a setting on the active input controller telling it not directly poll the keyboard state for isKeyDown. This is so if the user is in an edit box and typing "wasd" it doesn't move the camera.

I also took a look at the undo system and how I'm going to manage it with the fact that partitions are going to be loaded and unloaded dynamically around you as you move. This is tricky but I have an elegant solution for it.

tuan kuranes

20-02-2006 08:17:52

Nice !
although I don't yet have PLM2 up and running inside the editor
Arrrgh ! just when plsm2 cvs is broken against HEAD...
I'll try to fix ASAP and integrates the new scenemanager thing.

Falagard

20-02-2006 15:13:24

No big deal, I haven't even tried the PLM2 changes yet. Keep in mind I haven't updated my PLM2 code in about 8 months.

Jerky

22-02-2006 22:48:42

Wow, Falagard! You are getting a lot of things together rather quickly. That looks fantastic. If you have any ideas on GUI design, I'd be happy to help you put one together. From what I saw (I only have looked once), making a gui design in CEGUI is like make a texture from UVs. Let me know.

Keep up the great work!

jacmoe

23-02-2006 17:15:39

This is really promising!
Great work falagard and tuan kuranes. :D

Goof is The Main Way.

Yes, GOOF is the main way for my project too. :)

So that basically means that the core of my project cannot be written before GOOF is out. :|

But I don't mind waiting. :wink:

praetor

24-02-2006 15:51:18

Just to clarify about GOOF:

The map editor will use it as its core data, and when you export a map, it puts it out in GOOF format, right? There will be a loader similar to oFusion's where you can register callbacks as you load GOOF? I decided not to wait to keep developing, so I have my own model-view-controller set up with little room for GOOF to plug directly in. If I could use it's format as a persistent one and then just import them into my engine's format that'd be great. What are your thoughts on making a loader like this?

Falagard

24-02-2006 17:20:50

The editor doesn't just use the GOOF file format, it uses GOOF itself. Which means inside the editor you're running a game engine. That's useful because you may want to edit a huge world, and the partition system dynamically loads and unloads partitions as you move around the world inside the editor.

I am going to implement an observer system similar to the oFusion
oSceneLoader's system, but am assuming you're actually using the GOOF engine inside your game, not just the file format. By this I mean that GOOF might be loading and unloading objects on you, creating and destroying particle systems, etc. You'd be able to receive events for things like gameObjectLoaded, gameObjectUnloaded, partitionLoaded, partitionUnloaded, gameObjectLODChanged, etc. which will let you hook up your own objects to GameObjects if you need them.

Clay

Falagard

06-03-2006 21:38:08



Added Properties window to display properties of currently selected object. Properties window works with any object that derives from PropertyContainer class, so works with GameObjects, Partitions and eventually GameObjectManager. This basically means the same property window can be used to edit properties of a bunch of different types of things. For now it works with Objects and Partitions.

If you click the "Props" button in the toolbar it will display a property window that shows the properties of the currently selected object in the viewport. If multiple are selected, it currently just displays the properties of the first selected object. As you switch objects, the window is updated.

Added a "select objects" window which displays all objects that are currently loaded (like a scene browser basically) and lets you select multiple objects using Ctrl in the list. Also displays the partition the object is in. You can click on up to two objects and choose "Properties" to display two property windows at the same time. These are similar to the Properties window that is displayed when you click the "Props" button in the Toolbar, but will don't change as you select different objects in the scene.

You can switch the drop down from Objects to Partitions to display all partitions, and edit the Partition properties. I put some sample partition properties that don't actually do anything at the moment, but you can imagine what they'd be used for:

Skybox Material
Sun Direction
Sun Colour
Global Ambient
Background Music

You can imagine having different properties for each partition, and then cross fading between those as you move from one partition to another. You see the effect in games like World of Warcraft when you walk into a Forest the ambient colours go green, etc, or you walk into a fiery cave or a scary place.

I've worked on a lot of other things as well, however I got very ill over the weekend (some type of stomach virus that first had me vomitting for 12 hours, then just when I thought I was better, I had it coming out the other end for 2 more days) so I'm just getting back into it now.

Regardless, GOOFEd is progressing nicely.

OvermindDL1

06-03-2006 21:48:05

Definitally looking nice, can't wait to try to GOOF my current object system. :)

Hope you feel better now, and don't try to program when you're sick, personal experience...

Moug

06-03-2006 22:12:51

Wow that is looking really great.

Has the setup changed?
I tried following the document on how to set this up and well, I failed badly.

Falagard

06-03-2006 22:19:52

The code in CVS is out of date by almost a year. I'm not sure what state it currently is in. Within the next couple weeks I'll be updating CVS with my latest code which will include new information. The only tricky thing I currently require is you to download the latest compiled CEGUI SDK from the CEGUI website and use it instead of the one that comes with Ogre, since I'm using a few features that are specific to the latest version of CEGUI.

Clay

jacmoe

06-03-2006 23:02:16

Wow!
Looking great! - And I can't believe that the wait is nearing an end! :)

Is that CEGUI 0.5 (CVS HEAD) ?

Falagard

06-03-2006 23:53:17

Nah, it's CEGUI 0.4.1. I think the only reason I need it is because the CEGUI Layout Editor creates layout files that are only compatible with 0.4.1 and not 0.4

Falagard

14-03-2006 05:38:53

Okay, got some biggies in now. GridPartitionManager is in and seems to be working nicely. I redid the delayed loading code so that it is handled by the PartitionManager class instead of Partition class, so that all loading objects are handled in one place and can eventually be prioritized based on distance to camera, etc. Only one object is loaded at a time. This is cleaner and clearer than before. Also objects are in specific states now, such as "Ready", "Loading", "Waiting for finalization", "Finalizing" which is clearer than the previous set of boolean flags.

Partitions save their state prior to unloading into a state variable, and reload from this state instead of saved file.

Undo system is in place and works, including all possible operations on objects (insert, delete, rotate, move, change properties, link, unlink, select). Currently does full scene restore on all undo operations, but can be optimized for different operations later. Operations were tricky with the partition loading/unloading, but found a nice solution. If a partition is no longer loaded even though it was at the time of an operation, and the user performs an undo, I simply swap the stored state with that of the state for that partition at the time of the operation. Works nicely.

Redid all object handling from the editor to work on a list of names, so that if objects are unloaded I'm not keeping a pointer to a destroyed object, only its unique name, which I use to request the object from the object manager. If no longer loaded, it will return null at which point I don't use that object. Example - if a property window is open but the object gets destroyed, needed to handle that.

My todo list is getting shorter:

Copy/Paste
Terrain editor stuff redone in new framework
- includes terrain morphing - raise, lower, etc.
- splat painting and texture choosing
- new terrain generation and importing heightmap, generate via libnoise
- handle world geometry change
Port lightobject, particlesystem, sound object AND the sound manager, tree object, compound, sequential, markers and actor objects
Get shadows working on PLM2, with shadow property turning on and off per object
Occlusion culling naming convention and properties added to MeshObject for occluder/occludee
Split into projects, create plugins, read settings from config, add LGPL notes.

Jerky

14-03-2006 05:58:48

:shock:
Almost there. You are the man!

Question - I know you have mentioned a new scene format. Is this a GOOF scene format. Would it be able to import .scene and oFusion scenes? I didnt see that on the list ;). Or is that part of the plugins to be done later?

Either way, we are quite excited about it. This tool will rival anything out there.

Falagard

14-03-2006 06:25:27

Um, there's a GOOF scene format that is different from .scene and oFusion scenes, but it hasn't changed lately.

I'll be adding .scene and ofusion scene loading after I release this version as a later feature. Not too much later, but I need to get this done and dusted.

Clay

Jerky

14-03-2006 06:29:59

Thats what I thought. No worries, I was just clarifying.

Falagard

14-03-2006 06:36:01

I forgot to mention that I did complete copy/paste, so that's working.

duff

15-03-2006 07:15:51

good work again.

Hope you will release soon. Your todo list go smaller every day ;)
Have you got the go back button now ?

Falagard

15-03-2006 08:26:34

What's a go back button? :-)

duff

15-03-2006 10:52:30

I mean undo/redo ;)

Falagard

15-03-2006 16:59:48

I don't have buttons, only Ctrl + Z and Ctrl + Y for Undo and Redo. Currently undo/redo only works with object operations as I described in my post, not with terrain editing.

Razgriz

16-03-2006 03:42:51

First off, I'd like to say that from what I've read in this thread, GOOF is going to be simply amazing... Keep up the great work :D

Next, if it isn't too much trouble, can you post what you have so far since the cvs is outdated? I have no intentions of even trying to get it to compile. I'd just like to explore the source and maybe run doxygen once before the initial release if possible. No rush.

Falagard

16-03-2006 03:46:25

It's a few days out of date:

http://www.larabie.net/ogre/MapEditorSource-March11.rar

Razgriz

16-03-2006 03:50:15

:shock:
That was quick. Thanks.

Falagard

16-03-2006 04:41:11

That's actually not a very good code zip because it doesn't contain the solution file, it was a smaller backup without every that is needed. Hopefully it'll tide you over. Most of the .h and .cpp files not prefixed by GOOF are old and no longer used, and are in the process of being ported.

Razgriz

17-03-2006 04:13:35


That's actually not a very good code zip because it doesn't contain the solution file, it was a smaller backup without every that is needed. Hopefully it'll tide you over. Most of the .h and .cpp files not prefixed by GOOF are old and no longer used, and are in the process of being ported.


It's fine. I run Linux anyway so a solution file is not needed. If you ever need a Linux tester I'm willing :)

Falagard

17-03-2006 04:39:34

I will need a linux tester :-)

Naicigam

17-03-2006 13:41:26

I'm new to OGRE and this tool looks really great, but I don't have C#, so can anyone post the binaries for the source that falagard has posted?

Thanks in advance

Naicigam

Falagard

17-03-2006 16:57:12

I haven't posted enough source to compile it yet, and it wouldn't do you any good anyhow since it's not done, and it's C++ not C# :-)

If it were ready I'd post binaries myself, but at the moment it's in an unfinished state, I'm still working on trying to get it ready. It has blocker bugs that cause the program to crash and be unusable all over the place, and it doesn't even have any really useful stuff in it yet - stuff that was working before and I have to go through item by item and get it working again in the new framework.

Anonymous

22-03-2006 08:48:09

How's progress coming along on this?

Falagard

22-03-2006 15:54:18

Good. I'm now working on adding terrain editing functionality.

There's lots of work involved, including a lot of GUI work which always takes a lot of time. Here's a quick example:

I'm working on the new terrain wizard which asks you if you want to create a blank terrain, terrain generated via libnoise, or new terrain from a heightmap. This functionality has taken me many days just to create in CEGUI, hook up windows inside the app and general user interface stuff, without even getting to the part where I write the code for creating the terrain.

Plus I'm putting in functionality for new, save, save as, and open... but the code that I'm working with, which came from the old map editor code that Lucky Luciano did, only has new and open. The reason for this is because any editing you did to the terrain acting upon the one and only terrain, so there was no saving. My new code is going to deal with temporary terrain at all times. When you create a new terrain or load an existing terrain, it'll always generate a temporary terrain. Then when you save it'll copy the temporary terrain files, rename them or regenerate the various files as your saved file name.

All of this is taking far longer than I thought it would, but it is coming along and I am working several hours a day on the functionality. In the end it'll be worth it to have a working editor that lets you easily create and edit terrain without worrying about the map splitter and config files.

Another thing about the GOOF editor is that it will only support a subset of the full functionality of the PagingLandscapeSceneManager. I intend to support only one Texture mode, such as Splatting2, but add functionality for different textures per page and things like that that are not currently supported. I also need to figure out how to enable lighting on the terrain using normals for while you're editing so the terrain doesn't look "flat" while editing.

My roadmap before releasing is:
1. Finish the new/save/save as/open functionality with support for importing heightmaps and libnoise generated terrain. Some involves porting old code, some involves completely new GUI work and new code, such as the import functionality.
2. Add terrain raise/lower functionality by porting existing code from old MapEditor into new framework
3. Add texture painting with support for 4 textures per page. I know how I'm technically going to do this, by creating a material per page and setting the texture format to "Image", but I'm not sure how the UI is going to look for this yet.
4. Get the SoundManager working in the new architecture as a game system.
as a game system.
5. Port NonVisualGameObject, SoundGameObject, ParticleSystemGameObject, LightGameObject, MarkerGameObject to new system
6. Separate the source into different projects which compile into dlls, and link them all together as necessary
7. Add LGPL comments to all code except app framework and editor framework which are public domain.
8. Test
9. Figure out how to submit it to CVS
10. Document how to get it up and running

As you can see, there's still a lot of work involved to get to #10. Even if it took me a day for each item, which it will definitely take longer, it would be a couple weeks. I'm thinking 4 to 6 weeks still before I can release :-( I do think that I'll release an alpha version as a download sooner though, to see if people can get it running.

Future work for a following releases. Once I have the above code in CVS, these updates will come more frequently as each piece of functionality is added:
1. Port ActorGameObject for player movement and collisions to new system
2. Write a viewer application sample that loads the scene and allows you to move around in 3rd person
3. Get the CameraOrientedQuadManager working in the new architecture for trees
4. Port TreeGameObject to new system
5. Grass/folliage creation and rendering using ScatterGameObject
6. Imposters
7. Dynamic billboard creation using imposters

Clay

Anonymous

23-03-2006 02:32:36

Glad to hear you're working at full steam though Clay. :wink:

We all appreciate your dedication and fine work. One of our coders, Jared will be contacting you soon (probably by PM) concerning the possibility of helping you out in your task, as we have similar goals in this design.

-Cheers

Falagard

25-03-2006 04:09:24

Nothing too special. PagingLandscapeTool added to the editor. Got terrain creation via libnoise working. This involved lots of stuff but I won't go into it.

Added property dialog for changing properties on the GameObjectManager and Partitions. Added ability to change ambient, sun colour, various shadow properties, etc. on the whole scene via the GameObjectManager, as well as in each Partition. Eventually I'll add nice interpolation of all those values so that as you enter a Partition it interpolates from its previous values to its new values. For now it just changes immediately.

Added shadow support.



Jerky

25-03-2006 05:17:51

Looks great! Thanks again for yet another update.

jacmoe

25-03-2006 14:39:16

Really looks great! :D

Now, some collaboration with soconne, the FreeWorld3D programmer, would be absolutely great! :)

Falagard

27-03-2006 01:58:02

Jacmoe,

I keep flip flopping back and forth about whether I should just be really simple terrain editing features in and have the ability to import terrain from external apps like Freeworld, or whether I should put full features into GOOF to do the same things that Freeworld can.

Obviously, putting full features into GOOF would be best but would be a lot of work. However if I don't then it'll be hard to do some things in Freeworld and others in GOOF.

jacmoe

27-03-2006 02:27:08

Nah, I probably should post in the FreeWorld3D forum.
I am not after making FreeWorld3D a required part of the pipeline.
Right now, FreeWorld3D supports the general Terrain SceneManager, and does it well.
It would be absolutely great if FreeWorld3D could load a PLSM2 terrain, and vice-versa.
I am not saying that you shouldn't go for a full-featured terrain-editor - by all means! :)

I am looking for an easier route from L3DT and FreeWorld3D to PLSM2.
But I guess that's up to the authors of these tools.

Anyway, keep up the good work! Very inspiring, and promising. :wink:

praetor

29-03-2006 22:50:33

It doesn't seem too much to ask users to just import heighmaps from other apps. These other apps are already free and feature-rich. Just having support for loading their stuff seems fine. That gives you more time to focus on things we don't have. For instance, your work on trees was awesome. I haven't seen that kind of work in a free library before, and I'd love to see more work in these innovative directions.

Falagard

30-03-2006 18:13:09

Praetor, that's what I want to hear ;-)

The reality is that there's only a few things holding it back from being as good as Freeworld, however there's a lot of work involved. Perhaps someone else can jump on and help once I put out the simple version:

1. Undo/redo on the terrain deformation and painting.
2. Lightmap generation
3. Merging splatting layers, including lightmap, into a single layer. Although the MapSplitter can create a base map, this is just using single colors per texture and is not near as good as doing a render-to-texture. You can try the merging in Freeworld to see what it looks like - the merged version retains a lot of the detail from the splatting layers.
4. Generation of an alpha splatting layer's alpha values via parameters such as min height, max height, min slope, max slope. Although the MapSplitter can generate alpha splats by heights, I'd have to do all the work to add user interface and code changes to map splitter (or pull out the code and put it into the editor) for generating the alpha values after the map has already been split. This is one of the most useful features of Freeworld - to be able to play with the values and click generate and see what it looks like, then modify and click generate again.
5. PLM2 only currently supports raise and lower for deformation. We need smooth and flatten.
6. Road generation via splines.

In addition to all those features, I'm still working on just importing terrain from external programs, allowing you to specify the textures and alphas for splatting, etc. I'm trying to figure out how to deal with the number of splatting textures and alphas.

Clay

jacmoe

30-03-2006 20:01:34

I think soconne - the author of FreeWorld3D - is willing to ease the route from FW3D into PLSM2/GOOF.
He is very interested in OGRE, you know!
A constructive dialogue? :)

Falagard

30-03-2006 20:07:29

I don't think there's much soconne can do to make it easier, but if I find something I'll definitely request it.

praetor

30-03-2006 20:19:32

I remember a while ago there was talk of "regions" in the editor. Is that still planned. I thought that was the best solution for place things like trees and grass all at once. To recap, you would use splines to draw a polygonal area on the map. Once closed, you could set some properties on this region, such as objects that will be generated within etc. Any interest still in this?

Falagard

30-03-2006 20:24:17

Yup, that's still on my todo list, high priority since I'll be using it to generate grass. I'll also be doing something else for grass but you'll have to wait to see cause nobody will believe it's a good idea.

Oh well I'll spill the beans. There will be a RegionScatterObject like you described where you manipulate splines and close it, and a CircularScatterObject where you can just drop a circle on the terrain and it'll generate objects within the circle, and you can change its radius.

Now, imagine using a RegionScatterObject to scatter CircularScatterObjects inside the region ;-)

Not sure if I'll end up doing it, but I thought it'd be good for different types of clumps of grass in a field, or better yet, imagine clumps of flowers.

I have to take a big look at my static geometry code though at the same time, because it's currently not good enough to handle lots of grass, it'll bog down. I want to dynamically load the grass as you move around and try to make it happen over several frames to keep the framerate up.

praetor

30-03-2006 22:13:58

Someone somewhere had luck with a background that that continuously (when there was anything to be done) built static geometries. You could have a threadsafe queue and queue up entities and when you were ready (you queue everything up) issue a "bake" command. The background thread runs and bakes in the geometry to a static geometry (perhaps created initially and provided along with the entities to maintain thread safety) and notifies you when it is through. I image the "baking" is the slow part, not the adding of entities, and I can't see any way to spread the baking over multiple frames without modifying Ogre. Background thread may be the "best" way to do it.

I was planning on making several of these utility threads that perform generalized tasks life resource loading. This would definitely fit that category.

Falagard

30-03-2006 22:26:37

Yeah, I figure the baking part will take the time as well. I already have delayed loading of entities over several frames, as well as background thread loading of resources that just needs some tweaking to be finished.

Let's say I have a large field that is 512 x 512 meters which just happens to correspond to a page of terrain, and it should have grass across the whole field. That is a lot of grass and static geometry. Instead of creating one static geometry for the entire field, and let it break up the static geometry into pieces (static geometry already has the ability to specify a size and it'll break up the geom into pieces that large), instead I'll split up the field into multiple static geometry instances and only create and bake them when the grass is near the camera, and destroy when it moves away.

I'll actually have a sort of static geometry manager that will do this automatically, you just have to add entities and positions to it, and it'll handle it.

Eventually I may look into whether it makes sense to split the baking into multiple frames by modifying the static geometry code (or copy it out of ogre and into goof and modifying it) so that it reserves the full vertex buffer and then copies into it over several frames.

praetor

30-03-2006 22:35:08

It all makes sense. May I suggest that as you enter entities into the static geometry the max of the max draw distance is stored corresponding to that geometry. This might be overrideable, but this would be the default view distance used to make and show the static geometry. That way trees that are baked together with grass would be visible after baking to their proper view distance. View distance + large amounts of foliage is the most important thing in my mind for scene realism and immersion.

Falagard

30-03-2006 22:54:06

I'll document all this later, and it's complicated, but each object has a SizeHint and StaticGeometryRule. The SizeHint determines how many levels of detail the object has, when the LODs switch, and when the object fades out of view if it is not converted to static geometry. We need a different method for fading out static geometry, or we need to modify how the fading works so it works the same for both, but for now objects that aren't converted to static geometry are faded out by creating a copy of the entity's materials and then modifying the diffuse alpha until it fades to invisible. Static geometry will probably use a vertex shader to fade it out using a constant distance.

The StaticGeometryRule determines whether an object should get to converted to static geometry and when.

StaticGeometryRule:
1. Always convert to static geometry. If this is true, then the object will always be converted to static geometry regardless of distance. Grass mesh objects will have this set.
2. Never convert.
3. Convert when the partition that the object is in is not PROX_IMMEDIATE, which means that it's further than the length of a page, in the case of the GridPartitionManager. Trees and other very large objects with high polygon count will use this setting.

What this means is that trees won't usually be baked together with grass in the same static geometry, trees will typically be in a different set.

I need to do some thinking about when to actually bake and how. I have something in now but it's not working as desired.

praetor

31-03-2006 16:30:49

Do entities specify in the rules what geometry group they are to placed in? For instance when you add grass you tell it the name of the eventual geometry, or are static geometris created (named randomly) automatically on-demand with no input? I can see the second being useful, even if it means less control. Just tag something as static or possibly static and everything gets handled from there.

Falagard

31-03-2006 18:33:21

Currently it works like this:

A static geometry is created per grid partition and named similar to the partition. Static geometry on a partition that is near the camera has setRegionDimensions to break up the static geometry into pieces. Static geometry on a partition that is far away have one large static geometry for the entire partition without breaking it up. Once the camera moves within a certain range of a distant partition it triggers the partition to ask all objects to re-evaluate themselves to determine whether they should still be static geometry or not.

I'm going to change the system so that each grid partition is subdivided into static geometry "cells" and stop using the setRegionDimensions functionality of static geometry. These will be automatically created and named, and the entities to be merged into static geometry will automatically be slotted into the proper cell by the partition.

So far I haven't seen the need for more control over the static geometry, but if it becomes a problem, for example if grass should be in a different static geometry than bushes or something, then I'll reevaluate.

praetor

31-03-2006 19:17:10

Ok, so there's a grid system. One sg to each grid. The sg settings and what's in the sg is determined by the proximity to the camera. It all makes sense. I can see the need to a little finer control yes, because things like bushes shouldn't be in the same sg as grass. Here's the case, grass is always static, and then bushes come in. But grass needs to be faded out a lot sooner as the distance increases. Or one would think. I suppose this calls for tests to see how visual quality with multiple sgs and varying-sized objects relates to performance. Maybe the current system is actually good enough. Best not to assume anything.

Falagard

31-03-2006 20:48:51

If anything we could have 2 different levels of static geometry, one for small objects that fade at a closer distance, one for larger objects that are visible for longer. That could be done fairly easily.

wolfmanfx

02-04-2006 10:11:58

Has someone binarys compiled against win32? That would be great :)

Falagard

02-04-2006 22:26:12

Once it's ready, yes a demo will be available. Anything I put out right now will not work. End of story.

Anonymous

03-04-2006 03:18:28

Take your time mate. :wink:
A lot of people appreciate the work you're doing.

CrxGames

03-04-2006 22:12:59

I just played around with the April3 binary fal posted here(http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=819) and it's awesome. Keep up the great work! :D

Falagard

03-04-2006 22:36:20

If you download that version, keep in mind that it's an empty shell of an application at the moment without all the fancy objects that makes GOOF so much fun. I pulled them out before I uploaded cause they're not finished.

And the landscape tool is what I'm currently working on so it needs a lot of work. Having a problem with LODs ;-)

CrxGames

03-04-2006 22:44:28

If you download that version, keep in mind that it's an empty shell of an application at the moment without all the fancy objects that makes GOOF so much fun. I pulled them out before I uploaded cause they're not finished.

And the landscape tool is what I'm currently working on so it needs a lot of work. Having a problem with LODs ;-)


Well, I noticed a few issues with the landscape tool, but I was more impressed about how fluidly terrain creating and morphing works =).

Falagard

03-04-2006 22:56:23

Did LOD work for you? Did you see it changing levels of details?

For me I get really low res terrain. If I go into the tempmap.cfg and change maxrenderlevel to 1 then I see high resolution terrain only, but it gives you a better idea of the morphing working.

CrxGames

03-04-2006 23:15:45

Did LOD work for you? Did you see it changing levels of details?

For me I get really low res terrain. If I go into the tempmap.cfg and change maxrenderlevel to 1 then I see high resolution terrain only, but it gives you a better idea of the morphing working.


Nope =\, the morphing worked well, but it was very jagged, which I take to mean low LOD.

Falagard

07-04-2006 18:45:57

Update:

Fixed terrain LOD issues.
Worked on trying to make a nicer terrain morph and paint brush, using bmps. This should be working once I get the latest version of PLM2 out of CVS.
Changed all input to use OIS (Object Oriented Input System) and hardware mouse cursor.

Not a big list of changes, but took a lot of time. Terrain LOD issues took me a couple days to track down.

The brush stuff is important because the default morph and paint brush is generated by PLM2 but isn't all that nice.

The OIS stuff is VERY important because I wanted hardware mouse support (windows cursor) and an input system that can support joysticks and is better than Ogre's built in system. OIS took a couple days as well.

Clay

Falagard

19-04-2006 01:15:19

Okay, here's where I'm at:

Terrain morphing now works well with custom .bmp brushes, the morphing is nice and smooth. Terrain painting is currently not working due to a bug in PLM2 that I have to fix, or Tuan, whoever gets to it first.

I'm burned out on the terrain editing portion so decided to look back into the object framework and editing plugin again. There were quite a few bugs introduced by changing to OIS and minor changes to how the axis manipulators work, so I fixed those.

My todo list isn't getting any smaller, and I have some big real life events coming up over the next month that are going to slow me down (selling my current house - it's up for sale today! And just bought a house 4 hrs away that I'll only get if my house sells quickly) so I'm planning on releasing GOOF and all related stuff without all the features I'd hoped.

What I still need to do before releasing is:
1. Port light, particle system, sound, sound manager, tree object, compound object, and marker objects.
2. Provide a set of sample meshes to play with.
3. Split into projects
4. Add LGPL notes

That means that what I release will have the following problems or will be missing features I'd planned:

1. Not yet suitable for large outdoor scenes because I need to work on the static geometry implementation, as well as impostors and billboards for distant objects.
2. The grid partitions of GOOF don't match the position of PLM2 pages yet. My partitions are +x and +z from 0,0,0 whereas PLM2 pages do something else that I haven't figured out yet ;-)
3. Creating new types of objects, such as mesh objects, is a manual process which you'll have to edit .meta files.
4. No documentation besides code comments.
5. No true plugin system yet, this will require a way to register plugins using Ogre's dynlib.
6. Terrain editing is limited to morphing, painting doesn't work yet.
7. No import of heightmaps yet into PLM2.
8. I wanted to show multiple different scene managers working with the GOOF framework, but it will currently only show the PLM2.
9. Sample scenes don't exist
10. Snap to grid, snap to angle
11. LightObject level of detail
12. Actor game object and 3rd person controller
13. Unified material system
14. Mesh wrapper file with material assignment
15. DotScene and OFusion importers/exporters
16. Type in orientation via property dialog using degrees is broken
17. Import texture splatting layers
18. Smooth tool for terrain morphing.
19. General bug fixes - there are probably crashes everywhere.
20. Implement Fluid Studios memory manager and track down mem leaks.
21. Background resource loading
22. Messaging system
23. Threading management, state caching cross threads.
24. Stamp object for stamping down a region, such as a circle, and scatter other objects inside that region, such as grass.
25. Similar to scatter, a poly region object that does the same functionality but using poly region
26. Interior partition stuff

Some of the above list is wayyy beyond what I'd planned to initially release, but it gives you an idea of my todo list.

Jerky

19-04-2006 06:24:40

Congrats on the house and good luck with that. We really appreciate the hard work on the editor so far. Life happens :). The progress sounds great. I am sure we will all still get great use out of what you have so far. Keep us updated on the moving process :D.

Falagard

19-04-2006 06:31:17

Thanks Jerky.

I'll still be working on GOOF full steam of course, I have no intention of slowing down, but I think despite my best intentions the progress will slow down for awhile so I'm attempting to do what I can :-)

Falagard

19-04-2006 18:29:04

My house for sale:

http://www.flickr.com/photos/22814604@N ... 111346657/

praetor

20-04-2006 00:46:50

wow. It looks brand new. Did you have it built, or did you fix it up at all?

Falagard

20-04-2006 00:51:28

It's 20 years old, was renovated by the previous owners (we've only been in it for 3 years), but we've fixed it up nice as well by putting new carpet in the basement, painting it up in better colours than the original pink and blue, as well as other non visual things such as replacing the shingles on the roof, replacing the central air conditioner, fixing the gas fireplace, and better furniture ;-)

Falagard

27-04-2006 05:10:19

I took a few days off from the todo list and implemented this:

http://www.ogre3d.org/phpBB2/viewtopic. ... 366#144366

duff

27-04-2006 13:13:46

beautiful...
Hope you will release soon to make it possible for other dev to make some plugin ;)

Occulis

30-04-2006 16:32:50

Hey Falagard,

If the GOOF messaging system is still a wanted feature, I just finished a publisher / subscriber model which I'm very fond of. I am happy to contribute this to Ogre3D in general or GOOF in specific.

Falagard

30-04-2006 18:33:34

Yes, definitely, and I have no messaging system in place yet :-)

Occulis

01-05-2006 02:06:07

I cleaned up the PeerOS routines and "published" them to Ogre3D here:

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

jacmoe

01-05-2006 06:20:58

Not only did he do that, but he whacked it in the Ogre Wiki as well:
http://www.ogre3d.org/wiki/index.php/PeerOS

Thank you, Occulis! :)

Falagard

01-05-2006 14:57:59

Nice work Occulis, I've taken a quick look. I need to read it more clearly when I'm fully awake though ;-)

Falagard

06-05-2006 07:53:21

Update:

Been working on various things. Finishing up some sky stuff, although it's not completely done yet, I'm going to leave it as is. I want to make an EnvironmentGameSystem that handles the sky really nicely, and so far it's sorta just coded directly into the CoreGameObjectManager.

Continued working on porting the various objects into the new system and adding new features to them. ParticleSystemGameObject and LightGameObject are ported, and I added LOD support to the LightGameObject which means that lights now fade in and out depending upon their LOD just like everything else. If you have a large outdoor terrain with a dozen campfires, you only want the light to be enabled when you're within a reasonable range to actually see the light. When the light is in range, it fades into view, and when out of range it fades out and is destroyed.

Next I'm going to work on SoundGameObject, TreeGameObject and MarkerGameObject. I think sound and trees are going to take some time. I'm pretty sure I'm going to change over to fmod for the sound system instead of OpenAL, because fmod has so many amazing features that seem to blow OpenAL out of the water. Things such as allowing you to set a maximum number of sounds to play at one time, while still allowing you to create sounds - fmod will detect which are closest to the listener and only play those sounds, as well as crazy things like sound occlusion based on geometry. I'm not sure - I suppose I could add those features myself to the custom sound manager I've created. I have to give this more thought.

I've given some thought to a Corona object (glare off of lights rendered as a billboard, not the beer) that would go well with lights. This would basically be rendered in a different render queue over top of everything, and would detect visibility either by raycasting from the camera to the light every XX milliseconds, or potentially by using the hardware occlusion query system. I'd be nice to be able to shrink the size of the Corona based on how visible the light is, so if it is being viewed through leaves or something, it's just less bright or smaller, and not completely invisible.

Clay

jacmoe

06-05-2006 14:03:44

Really looking forward to seeing it! :)

bibiteinfo

06-05-2006 15:44:37

Can't wait to see it out!!

For license stuff, shouldn't you stay with OpenAL since FMod is free for non commercial license, but you need to pay for commercial license?

When it will be out, it should have it's own forum instead of a 13 pages thread!

You're making a really good job, continue like that!

Razgriz

06-05-2006 18:10:11

The shareware licence is only $100 a title for FMOD which is very reasonable. FreeSL which uses OpenAL and supports some advanced sound effects using the EAX library such as occlusion and environmental blending maybe an viable alternative to FMOD. The license allows you to chop it up and do pretty much everything except sell it, so you can use it as base for you own sound manager as another option.

Falagard

06-05-2006 21:04:56

Ya, the other big thing that fmod supports is automatic background loading of sounds.

I just looked at FreeSL and it does have a fslLoadSoundFromData which means I can background load it from disk using Ogre and my DataStreamResource class, so perhaps I'll look into that.

Falagard

16-05-2006 07:22:54

Worked on background resource loading class - cleaned it up and ready to re-implement into certain objects that need to background load, like MeshObjects, and eventually the environment game system.

Created an Ogre resource class for DataFile so that loading XML can be managed by Ogre, and also eventually background load the XML so that it doesn't slow down the game while loading partition data.

Integrated tuan's impostor manager code and almost got it working in one night! I implemented it as a GOOF game system, had to modify MeshGameObject so it created its own node and attached it to the node created by CoreGameObject so that the impostor system can remove the node without affecting the rest of GOOF. By "almost got it working" I mean that the system is in place, being used by MeshGameObject, and the impostor is apparently getting rendered to texture, but is not showing up in the scene yet. Not sure why, as the mesh's node is definitely being hidden by the impostor handler.

jacmoe

16-05-2006 23:38:47

Wow, this really sounds promising! You've been busy! :)

Seraph

17-05-2006 13:27:54

@Falagard I have the same problem when integrate the impostor code . I dump the impostor render texture to file . it looks ok. but the impostor didn't show up in terrain. strange...

Falagard

24-05-2006 01:50:19

Impostoring has been temporarily put on hold - it just needs some tweaks anyhow.

Since tuan fixed the terrain painting, I've spent some time with the terrain editor plugin so you can select which of the 4 textures you want to paint, fixed some bugs, etc. so painting now works pretty nicely - especially with my brush handling to blend nicely using opacity. There's a bug in PLM2 texture blending though that needs to be sorted out.

Unfortunately with the fixed painting comes broken deforming, which was actually working nicely before ;-)

The loading/saving code for terrain from the editor is and always has been broken, but I'm working on it now. It's a bit tricky to handle "Save" and "Save As" like you'd expect in an editor.

For example, when you paint or deform terrain in PLM2 it flags those pages as modified, then when a page is unloaded it writes out a heightmap and alpha texture with .modif appended to the name. To get this to work as I would expect, I had to do some funky stuff - such as when you click "Save" I unload the terrain which forces it to save - then I loop through the directory looking for .modif files, delete the unmodified original file, and rename the .modif files to the original name.

The PLM2 also looks for .modif files when loading terrain and uses the original - which in my case is not desired behavior, so when loading a terrain I delete all .modif files prior to loading the terrain.

Save As functionality means you want to take an already loaded terrain and save it as a new name. I copy and rename all files from one terrain folder and move em to another, and modify the .cfg to use the new name for the terrain.

Should be done this soon.

Clay

Falagard

25-05-2006 01:13:04

Impostoring is working, but needs testing. Seems lighting is off, and may need to add code to recursively render all child scene nodes into impostor as well as an option.

Save/load terrain is working but needs testing.

mecovili

27-05-2006 02:02:50

Hey, Falagard.
First of all, great job!
GOOF looks really promising.
I was just wondering when it will be released,
and when released, how much functionality it will have?

Falagard

27-05-2006 03:10:11

I'm releasing it in early work in progress state as I continue to develop it, and as soon as possible (couple days to a week).

I'm going to set it up on ogreaddons.

I'll let everyone know what's missing, but basically it's a preview/early version that isn't ready for production. It'll be missing tons of features, but give developers an idea of what to expect.

Clay

jacmoe

27-05-2006 03:11:48

You can definately count me in as one of the early adopters! :)

syedhs

27-05-2006 07:19:23

Sounds very inspirational! The mapeditor is going to fill the biggest gap in Ogre production pipeline. I will not hesitate to contribute within my own expertise once I understand the PLSM2's working. 8)

Cutter

27-05-2006 17:34:31

Falagard, i`m watching this topic since it`s first page and every single post from you impressed me even more than the one before! I will definately use your Editor and perhaps GOOF, too, since there are tons of great features (impostors, paging of game objects, grass/tree system, lod system, ...; not sure how far these are integrated yet, though) which I wanted to implement myself one day.
Keep up that work!

ghostlake

30-05-2006 03:00:17

The topic is really hot and the MapEditor is really promising.. I am waiting for it realease. It seem has take you more than 1 year to do it...
===
Any chance to test this Map Editor is great... Hope it will be released soon.

Falagard

30-05-2006 03:58:45

I've been working on it more than a year yes.

Falagard

31-05-2006 04:43:47

Oh man, I just had the nastiest bug mess me up for several hours.

I made a bunch of pretty heavy changes to the code by adding class factory code for game systems, meaning that you can register new game systems through a plugin system, as well as making a new type of game system that is tightly coupled to the game object manager, and the ability to add dependencies to certain object types so that they create a game system if one doesn't already exist (such as a MeshGameObject depending on the ImpostorGameSystem so if one doesn't exist, it is created and added to the GameObjectManager). This is one of the last things I really wanted to get done before releasing it, since it's a pretty big change.

Anyhow, so I added all this code, got it to compile, but when I go to run it I was getting an error "The value of ESP was not properly saved across a function call" during a certain point. My first thought was that there was some weird problem with the way the class factories were implemented, etc. I googled it, found some various reasons why this might cause a problem, and tried all solutions. Nothing worked, and there actually didn't seem to be a problem. The crash was happening right after I attempted to perform collision detection against an object, and so I figured it was because I had just modified CollisionGameSystem quite heavily.

Okay, ready for it? The crash was actually happening in GameObject::getWorldPosition() but I figured it was a corrupt stack. Nope, I had two GOOFGameObject.h files into two different projects - I had accidentally copied it into the GOOFGameObjectEditorPluigin project as well as its rightful place, GOOFCommon. I had modified the getWorldPosition() function to remove a parameter I no longer needed, which had a default value.

Long story short, I had two header files with the same name in different projects, one with getWorldPosition() and one with getWorldPosition(bool ignoreHeight = true) and it was messing things up royally.

Wow. Anyhow, that solved, I'm on to the next on my todo list.

ghostlake

31-05-2006 05:50:48

Alot of feature that an editor could have, Falagard - sound great.
==
Looking for your next post about the progress of Map Editor

trung

31-05-2006 06:29:13

I think this is the time when you should release the code. I cannot wait more.

Falagard

31-05-2006 06:33:39

If you cannot wait more then ask Wolfmanx for access to the SVN server that he's already put up. I'm working out of that source control.

However, if you can't wait anymore then you shouldn't be using GOOF - it's not ready for production even when I release it in the next couple days.

duff

31-05-2006 11:13:34

hope you will fix your bug ;)
I know that it is an amaising job.
So, I wait your release with a lot of hope.
I have ever try some little things in it and so so good ;)

posixninja

31-05-2006 13:23:56

since the first bits are going to be released in a few days, I was wondering if you've already decided on a licence for your project?

Falagard

31-05-2006 15:09:56

Of course, stated time and again, LGPL with some parts public domain.

Paulov

31-05-2006 19:10:40

HI__
I would like to make just an small proposal that coders may find silly but for artists like me who only master 3D soft and dont know nothing about programming will save a lot of problems.

When you release the editor could you please release it with an installer?.
I told you this because if 3D dessigners have to be "playing" with the source to build it or watever...,many of us will get lost.

I´m also wishing to test this editor and send you a feedback of the things that work-dont work, what I likie/dislike etc

bye

Falagard

01-06-2006 01:44:20

I've recently sent a request to Sinbad to add GOOF to ogreaddons.

posixninja

01-06-2006 14:39:58

Of course, stated time and again, LGPL with some parts public domain.

sorry, didn't feel like plowing through the 15 pages of comments.. sheeshh

tuan kuranes

01-06-2006 15:05:28

@Falagard : don't forget to ask for you own forum too...

Falagard

01-06-2006 16:36:11

Good idea ;-)

duff

01-06-2006 16:51:23

very good news.
Maybe this can lead to a real project with other people to help you !!

ghostlake

03-06-2006 04:30:39

ah ha. 2 days without any info about the GOOF and map editor. Waiting now 8) . Maybe Falagard is working hard :wink: :idea:

posixninja

03-06-2006 11:56:21

I was getting some CVS errors last night saying directory GOOF was locked or something, I was told he was uploading it, but as of today I don't see it in CVS

Falagard

03-06-2006 16:25:48

I'm out of town actually so can't work on GOOF. I've not yet put GOOF into CVS - it's a lot of work (maybe 10 hrs or more) to get this ready for CVS plus instructions and dependencies.

trung

04-06-2006 18:32:39

I got the GOOF package you sent in May 2006 in the thread about CVS. I'm waiting for the CVS release with dependencies and build instruction.

Caelin

05-06-2006 12:15:02

I have been very impressed with this project you are taking on Falagard and I am now planning on using this framework and editor in a couple of games I am planning on creating so I am anxiously awaiting your release of this. Me and the other programmer I am working with would definately be interested in helping you with this project in any way we can. At first however we won't be able to help a whole lot as the first game we are releasing is learning based using 3D graphics and will be pretty simple. Also we have a tentative deadline on getting an alpha/beta release in about 3 to 4 months time so as you can see we won't be able to help much until that project is done. After that however we will be devoted to helping you with this project as it seems to be perfect for the MMORPG we are planning on creating.

Keep up the great work!!!

Falagard

08-06-2006 06:10:48

Thanks for the words of encouragement.

One thing I should definitely point out is that if you're expecting to evaluate GOOF and be blown away by what's there, you won't be. This release shouldn't be of much interest to artists or non programmers for example (I'm not speaking to anyone in particular here, just a general comment). The reason for this is that GOOF editor is buggy, is sometimes hard to use, frustrating, and generally unpolished at this stage. Getting things into the editor currently requires editing xml files, which artists typically won't want to do. The terrain isn't lining up with the grid partitions, so mostly everything you place on the terrain ends up in partition 0,0 anyhow. Anything you play with now in GOOF will most likely be completely useless as the weeks go on because of changes in the file format, or whatever.

So at this time what I release is going to be technology preview, and even the technology is limited ;-) Pre-alpha.

Clay

jacmoe

08-06-2006 20:10:33

Is the GOOF framework usable?
I'd like to start integrating it into my *engine*. :)

singotos

11-06-2006 10:38:55

This is really a good news. Hope GOOF and Map Editor could be release in a couple days next . :)

trung

11-06-2006 14:46:06

I've recently sent a request to Sinbad to add GOOF to ogreaddons.

It is difficult for you to request somethings if you have not released anything ;)

Falagard

11-06-2006 20:32:12

No it's not, Sinbad gave me a GOOF directly the same day I requested it.

If you guys don't want to wait, maybe you can go find some other engine based on Ogre? :-)

I'm working on things. It'll get done when it's done. I'm trying my best.

duff

11-06-2006 21:34:42

stop crying because goof is not release.
falagard do that on his own free time and he have do the choice to release it on GPL. All good project take time. I am working on different open source project and I am really fed up of people who ask for thing now whereas remember that he is not paid for that and open source is an hobby.

@falagard : keep doing your great work, it is people like you who make things go on... And I prefer something well designed and finished later than something buggy and features-less quicker

jacmoe

12-06-2006 01:53:08

@falagard : keep doing your great work
Word! :)

trung

12-06-2006 02:29:13

Anyway, I got "GOOFSrcMay14-2006.rar". It is not documented so I'm waiting for the runable version. I need only the runable version, to integrate network, sound lib... to ensure it built OK. And while waiting for the complete version, I could work for other parts.

Falagard

12-06-2006 17:48:58

You guys are probably wondering WTF I'm doing that's taking me so long.

A series of things has happened. Previously I was using fixed function rendering for the terrain using Splatting2 texture mode. I also had a nice sky system in place which used skyboxes, sun directions and fog colours for transitioning throughout the day. This worked with fixed function Splatting2 terrain so the terrain was properly lit and fog looked okay. I decided to switch over to SplattingShader texture mode because it's the one that's the best for performance of painting textures, etc. The problem with SplattingShader is that it's using vertex and fragment programs, so my old code which relied on fixed function lighting needed to be changed. Ditto with shadows and fog. This meant I actually needed to add lighting to the SplattingShader, as well as shadow support.. I wanted to add support for directional and point lights to the terrain and needed to figure out Ogre's systems for these features.

You might have noticed last week or so I posted an updated SplattingShader that supports shadows, and Tuan updated PLM2 with this code. You might have also noticed that I've been posting a whole crapload on the main forums about shaders in general.

What I've been working on is getting these features into the PLM2 so that it supports all this stuff, but additionally I've decided to bite the bullet and work on my managed material system for GOOF since I had to figure out the shaders anyway.

What is managed material system? It's the coolest thing ever made. Really.

In a nutshell it makes it way easier for artists to add fancy shaders to a mesh without needing to worry about the intricacies of how they work. Even though oFusion is pretty cool in 3ds Max to be able to add shaders and preview them in Max, it's still only part of the equation and pretty tricky to get working. The other part of the equation to working with oFusion is to actually write all the necessary shaders, and have them working with the plugin.

Image instead of having to worry about all that, all you had to do was fill out a set of simple properties and it'd determine the best shader to use for you and set it all up for you automatically.


DiffuseTexture="Brick.tga"
BumpTexture="BrickBump.tga"
EnvironmentMapTexture="Sky.tga"
GlossMapTexture="BrickGloss.tga"
DiffuseColor="1 1 1 1"
SpecularColor="1 1 1 1"
AmbientColor="1 1 1 1"
EmissiveColor="0 0 0 0"
SpecularShininess="16"


Well, what's so cool about that? Doesn't look very much different from an existing material file right? Wrong.

First of all, working with shaders you need a material that has a whole lotta stuff in it. And it changes depending upon the features you want, you need different shaders in the material file. For example, if you don't want specular, you should use a vertex and fragment shader that doesn't do specular. If you want bump mapping + specular it's a different shader than if you just want bump mapping and no specular. If you want a bump mapped specular environment mapped object, different again. There are a lof of different combinations to make. Hardware vertex animation? Modulative texture shadows, or Additive texture shadows? All of these are set up differently.

Now factor in that you might want to have different material lods so that it turns off certain high cost things like bump mapping at a certain distance, and that you want to have fallbacks to completely different shaders for different hardware, and you're getting very very complicated.

That's where managed materials fit in. You fill out that simple set of data above and it figures it all out for you. Magic.

The other nice thing is that the shaders and code that generates the materials for you can be updated later on with better performance shaders, better fallbacks for other cards, etc. without you having to go through 1000 materials and do it all manually, or having to write a script to do it. For example, the initial implementation I'm working on only supports shader model 2.0 cards and if you have lower, it falls right back to fixed function. Later on, I can add support for shader 1.1 cards and presto, no need to go back through your materials since you've just used the simple configuration file for your mats.

I won't get into any more details just yet but I've got most of the shaders complete for point and directional lights with different combinations of bump, spec and reflect for modulative shadows, and I'm just going to work on additive shadows. I'm going to skip spot lights until later, as well as hardware animated versions of the shaders later. I'm going to put together the material selector class that does all the work to assemble the material, and then I'm done that part.

I know, I know - it wasn't on my list of things to finish before I release but I wanted it done and I DID need to figure out shaders for the terrain anyhow.

Here's a list of shaders I've written. You can see from the list the different combinations. DirectionalVP2 and DirectionalFP2 just does directional diffuse light with no specular or bump, for example.

AmbientVP.cg
DirectionalFP2.cg
DirectionalVP2.cg
DirectionalSpecFP2.cg
DirectionalSpecVP2.cg
DirectionalBumpFP2.cg
DirectionalBumpVP2.cg
DirectionalBumpSpecFP2.cg
DirectionalBumpSpecVP2.cg
EnvFP2.cg
EnvVP2.cg
EnvBumpFP2.cg
EnvBumpVP2.cg
PointFP2.cg
PointVP2.cg
PointSpecFP2.cg
PointSpecVP2.cg
PointBumpSpecFP2.cg
PointBumpSpecVP2.cg
ShadRecFP.cg
ShadRecVP.cg

And it wasn't until I was typing out this list that I realized I have forgotten to write both PointBump shaders. Doh.

For additive shadows there has to be a shadow shader for each of the light shaders above, so for example PointBumpSpecShadRecFP and VP. Pretty simple to write these as they're mostly copy and paste.

Hardware anim will require XXXAnim version of the vertex shaders.

And all of this is for single texture only. If lightmaps are required, they need their own set as well. Lightmaps support will come later ;-)

Modulative shadows are done ShadRecVP and FP and don't need any other shaders, however I'm currently having a problem with them and have asked for help on the forums.

Clay

ghostlake

12-06-2006 18:01:32

It seen a ton of thing u must finish b4 release the first version of Map Editor. Seem It is very very powerful now :)...far from my imagination
===
Keep on your great work :P Falagard

praetor

12-06-2006 21:00:39

I had been thinking about this before, a system that was like a library of shaders, and it would pick the best one for you. I figured it was way too much work in the end. Here you are tackling it. Very brave of you.

To top it off, it needs to be very easy for an artist to still write their own shader. I figure they can just directly access Ogre for this. But what about making it easy for them to hook new shaders up into your system to be "selected?" Obviously you could never anticipate all the different wacky things people do with shaders.

Falagard

12-06-2006 21:25:41

Hi Praetor,

I won't be initially providing hooks into this system. If artists want to include their own shaders they just don't use a managed material. I can't see artists wanting to create their own shaders based on my own experience, but if they want to they can - and copy and paste parts from the shader library I've created.

The actual shader library isn't very hard to assemble. A couple days of work, plus any problems trying to figure out Ogre specific issues. Used a similar system for the MyVirtualHome software, where artists would use a database administration tool for setting up the materials on each mesh, but we actually had far more advanced shaders due to requirements that go beyond most game requirements for shaders. http://www.myvirtualhome.com.au

suzi

13-06-2006 18:11:48

Hi,

I like very much the mapEditor screenshot. :D

I am looking for the last version of mapEditor (the source and the precompiled version if it is possible). Also, I would like also to know if it is possible to save terrains as .mesh which will be great.

Thank you very much, :)

Suzi ^^

Falagard

13-06-2006 19:17:19

It's not yet possible to save terrains as a mesh - but I plan on adding it eventually. Probably as a .obj though is more important than .mesh.

suzi

13-06-2006 19:24:09

Yes, ok,

But is it possible to have the source of mapEditor ?

Thank you.

Suzi.

Falagard

13-06-2006 19:36:08

Do you want to be able to compile it? :-)

suzi

13-06-2006 19:41:55

yes, I can try :)

Falagard

13-06-2006 19:44:09

You can try, but you won't be able to unless I put it in ogreaddons with a list of dependencies, where to get them and how to set them up, which is what I'm doing right now (for the next 30 mins - then again tonite for a couple hours, and for however long it takes me to get it all done).

So... wait.

Falagard

14-06-2006 07:27:19

http://www.ogre3d.org/wiki/index.php/Ga ... _Framework

GOOF is now available in ogreaddons, or if you have anonymous access it will be whenever the anon server is updated.

Follow directions from the above link. Notice I added UML class diagrams as a general overview of how the systems interact.

Also note that the current version of GOOF is a moving target and I'll be updating it constantly over the next... oh I dunno, couple years. The current version is buggy and unstable, and not feature complete.

I don't really want to hear about bugs at the moment, errors, warnings, etc. but do feel free to fix anything you think you've found and post the fix here. I'll be setting up a dedicated addons forum here soon, if Sinbad lets me.

Clay

duff

14-06-2006 09:23:27

excelent news.
UML diagramme will help to understand how use it and how it work thanks for work and docs ;)

ghostlake

14-06-2006 11:20:23

Super *THING*. I am getting from the CVS and will try to compile soon

Falagard

14-06-2006 18:57:41

Updated the formatting and instructions in the wiki to make them more readable.

Falagard

14-06-2006 19:40:29

Ha, if you got it working you might be wondering why any meshes you insert into the scene are ending up purple. Ya, I was working on shaders and that was some test code. I'm fixing that now.

Falagard

15-06-2006 08:25:58

Found and fixed a bug in Ogre that was prevent modulative texture shadows from working when using shaders. Whew, that was a thorn in my side. Additive textures are still not working for my shaders and I haven't figured that one out yet. I'm going to leave it for now and just use modulative texture shadows for the moment.

Submitted a patch, but it might take a while before it gets accepted. In the meantime I may have to provide a modified OgreSceneManager.cpp file in ogreaddons if you want shadows working with my shaders.

Clay

wolfmanfx

15-06-2006 10:35:19

splattingshader5 works with modulative texture shaodws in eihort but have u got working vertex lit with shader?

Falagard

15-06-2006 16:54:16

Not yet, but it's coming.

Anybody actually get GOOF compiling? People ask for it and then I get no feedback. Perhaps it's a case of "my mother told me if you have nothing nice to say, don't say it at all" in which case, that's cool.

As I've been saying, GOOF is currently in a state where there's nothing fancy to show except the architecture. At least when I get done these shaders I'll be able to put together a fancy scene.

You're going to love these shaders. I do :-)

jacmoe

15-06-2006 22:26:22

I pulled GOOF from the CVS with great joy! :)

Haven't had the time to look at it though ... :wink:

Too busy fixing OgreOpcode.

Speaking of which: I see that you ripped it off, and I don't mind.
You are a better programmer than I am, so I'll just rip it back.
Looking forward to seeing what improvements that brings! :P

When OgreOpcode and OgreSteer is well underway, I will have the time to dig into it.
Looking forward to doing that, Falagard. :)

Falagard

15-06-2006 23:26:28

Yup, I ripped an old version of OgreOpcode back when you were doing things differently about ... I don't know, 8 months ago, and modified it. I figured you'd might catch me ;-)

PatrickB3

16-06-2006 01:49:15

I downloaded it too. Took some minor tweaking ( creating some folders ) to get it to run and to figure out only Debug Builds work. Other than that it runs. Since it doesn't do much can't really say much other than it runs.

You already know all the things not working in that version. :wink:

Falagard

16-06-2006 01:56:48

Cool, thanks for letting me know it runs and compiles. I've fixed the missing folders problem now.

It does a lot more than it currently shows, but I need to pull it together over the next few weeks to show it off.

Seraph

16-06-2006 07:47:38

just finish compiling the whole GOOF stuff, it runs ! but the terrain is missing....

Falagard

16-06-2006 07:51:37

Terrain is messed up at the moment, give me a couple days to fix.

bravery

16-06-2006 08:34:16

Falagard

Is there any documantation for your GOOF?

I'm in downloding and installation process now (for ogrenew and goof) but I'm new to OGRE so is GOOF easy to learn and use for newbies?

thanks in advance

tuan kuranes

16-06-2006 09:29:03

you mean, apart from the link to goof wiki documentation posted on top of page 17 of this thread ?

bravery

16-06-2006 10:14:57

that link is good but I beleave it's not enough to start learn how to deal with GOOF specially for newbies, I'm downloading the ogreaddons now (to check GOOF) I hope that it have a good samples to show all the functionality of this greate framework, but my question is: is it easy to learn and use?

jacmoe

16-06-2006 10:18:03

@bravery:
GOOF is *not* for newbies - it is a pre-release beta testing *release*.
Use it at your own discretion.
And don't expect any books about it.
If you know how to read C++ code you should be fine, otherwise: use something else. :wink:

Zvejk

16-06-2006 13:01:32

Well, I think its not so hard to install and run, if you know your IDE and sure you muset know C++. :lol:

I didnt tested GOOF yet, cause i am working on the PLSM tutorial, which I promised to jackmoe and Tuan Kuranes.
But after i see these messages, i tryed to install GOOF using Ogre Wiki and i think, not great, but sufficient. I think, with some modifications in the projects, it could work also with OgreSDK. Didnt have time to try.

praetor

16-06-2006 14:16:18

@bravery:
GOOF is *not* for newbies - it is a pre-release beta testing *release*.


Even worse! I think it is classified as pre-alpha!

Falagard

16-06-2006 14:19:21

hehe, pre-alpha. yup.


I'm downloading the ogreaddons now (to check GOOF) I hope that it have a good samples to show all the functionality of this greate framework, but my question is: is it easy to learn and use?


GOOF isn't ready for you, son. Take a break and come back in a few months. There are no samples. This "release" is intended as something of a technology preview so people can look at some of its internal workings.

ghostlake

16-06-2006 17:00:41

Hope you could make update soon and make the pre-alfa could compile with release mode and the PLS could run.
==
With a fresh, runable version, we could look into GOOF. At first time, we do not think we could help you develop something with GOOF 8) :lol: , but we will try our best to write document about it on Wiki :roll: :roll:

Falagard

16-06-2006 22:15:25

I've got terrain loading, and lighting working, unfortunately the deforming and painting isn't working while Tuan makes some fixes (I assume).

wolfmanfx

16-06-2006 23:44:35

What terrain lighting is working? if true really great job man :)

tuan kuranes

17-06-2006 13:02:23

unfortunately the deforming and painting isn't working while Tuan makes some fixes (I assume).
SplattingShader painting should work now. Be sure to update terrain config files and plsm2 materials too.

trung

19-06-2006 09:02:19

In the installation page, you posted an installation guide for all packages include Ogre, OIS. So you should remark for DX9 SDK download. It's required by OIS and some core modules of Ogre.

Falagard

19-06-2006 20:48:30

Thanks, I'll make a note of it.

trung

21-06-2006 05:07:40

And also, Plugin_OctreeSceneManager project should be added to the solution because Plugin_OctreeSceneManager.dll is required by GOOFEd.

singotos

22-06-2006 02:21:50

I also compile GOOF when u first release it but can not see the terrain. I know this is a problem with PLS and tuan has worked to fix it
===
I update CVS today and see there are some update with PLS. Is this update for GOOF and we could use terrain in GOOF now (except the saving, loading terrain I think still bug with it)

Falagard

22-06-2006 02:54:04

I'm still working on terrain. Give me a couple days. In my local code that I'm working on, saving and loading terrain is working, and everything else, I'm just trying to get the final lighting stuff in, and I am working on code to perform render to texture to automatically generate base textures that look identical to the splatting textures, as opposed to the base texture calculation that happens during map splitting which only goes by colors.

I may have to stop working on that part though since I've been doing it for a couple days now and haven't got it working.

ghostlake

22-06-2006 08:07:00

Sound great, looking to the first release of GOOF , not the pre-alpha 8)

Falagard

28-06-2006 06:47:45

Update just to let you know I'm still working on it:

FIXED:

General stability fixes
Compound object save/load fixed
Terrain texture problem fixed after loading world
Save/load world wasn't working in all cases
Fix partitions so they start at world (0,0) and move outwords in all directions the same as paging landscape pages

TODO:

My todo list in no particular order, and some of these are lots of work:

Check crash in void Traversal::traverseChildren(PagingLandScapeOctree& node)
Add check to terrain load to see if file exists
Copy/paste testing
Undo/redo testing
GameObjectManager save/load stuff
Dynamic properties on Partitions and GameObjectManager - possibly put in PropertyContainer
Rename PropertyContainer to PropertyOwner maybe?
Look into creating a unified system for fading in and out
- CoreGameObject. Update per frame, etc.
- Update mesh to use new fading system.
Static geometry handling system
- Add mesh name + position to static geometry manager and it handles
creating static geometry areas as necessary
Distant geometry static geometry?
Material manager
Sound game system
- get working for OpenAL
Background resource loading
Sorting loading objects by distance from camera
Interior partitions
Mesh animation
Message management + thread management
First person and 3rd person movement control + animation synching
- Collision detection
Environment game system
- Figure out how to deal with sun (load positions from xml)
- Figure out how to deal with skyboxes of varying time interpolation
- Fog, Ambient, Emissive, Sun Colour, etc. at time intervals
- Shadow colours
- Transitions between different skyboxes and values and how that works - make it as simple as possible. For example, can only transition at key points, waits to transition until key is fully reached.
Impostors - give me full control over impostors or work better with impostor system
Add Marker object type
Add sequential object type
Implement folliage object with sequential object stuff
Link parent should select the parent
Hover should show object name

Cain

28-06-2006 23:46:52

I've read in this thread, that there were issues in compiling GOOF in release configuration.
I don't know if these problems were solved in the past, but I had some issues in compiling the version in release configuration, which was in cvs today.

I found this out:
- to get the GOOFExtension project compiled you have to take the GOOFPagingLandscapeDecalGameObject.cpp out of the build process. (Like it's in the debug config)

- to get the GOOFPagingLandscapeEditorPlugin rid of the linking errors, you have to add _MAPEDITOR to the preprocessor defines (Like it's in the debug config)


After these two changes (beside adding directx9 includes and libs to the accordant paths, etc...) I got the whole thing compiled.

I think linking GOOFPagingLandscapeEditorPlugin to the Plugin_PagingLandScapeSceneManager2.lib isn't necessary, even if it's done in the debug config. (If I remember right.)

After compiling I had to fumble around with the cfg files in the execution dir, but now it works for me.

EDIT:
I forgot... I have no Textures in OpenGL, just plain white.

Falagard

29-06-2006 00:16:10

Release mode still isn't set up yet, but I'll do that soon.

I'll double check OpenGL, what's your 3d card?

ghostlake

29-06-2006 05:36:20

I think there are bugs with partitions. Switching between partition and create object my cause error

Cain

29-06-2006 08:40:47

Release mode still isn't set up yet, but I'll do that soon.

After these two changes the release config worked.
No 5 Minutes. (After you know where to look.)



I'll double check OpenGL, what's your 3d card?
I've got an ATI Radeon 9600.
OpenGL is working with other engines.
And with the OgreHead-Application.

Im using VC++ Express 2005, i could give you my solution, but there are some problems with directx wich is installed in different locations by any user.

Falagard

30-06-2006 00:46:58

Thanks for the tips, I'll be submitting fixed release mode stuff tonite.

DirectX should just be added to global includes and lib, not per project.

Latest fixes:

Fixed problem with grid partitions determining if point is in partition.
Completely disabled static geometry handling (again but this time properly).
Removed frameStarted and frameEnded from all InputListeners and instead made it update().
Fixed the time delta passed to update() to be at a maximum of 1 second. Fixed release mode build.

Falagard

30-06-2006 00:57:49


Switching between partition and create object my cause error


Can you elaborate? What do you mean switching between partition and create object?

ghostlake

30-06-2006 10:48:23

That s what I guess now :)
===
I mean If we try create object on different partition, the come back to a previous partition and then the error appear.



====

Falagard

30-06-2006 16:29:09

That's fixed already, get the latest code.

maxxoros

01-07-2006 05:12:43

This is a scene a make with GOOF May25 that Falagard make a release for download



It seem great. In the scene, terrain shadow is so cool and ambient light could set to 1. With ambient light set to 1, the polygons on model could not be seen and we could ignore the low poly of the model
=======
In GOOF newest CVS, I could not make shadow terrain work also If I set ambient light to 1, the scene like here. Terrain turn to white

=========
The first scene archive the effect that herro V is used. Ambient light = 1 and terrain shadow is enable


How could I archive this scene with newest editor.

Falagard

02-07-2006 06:14:57

Don't turn the ambient all the way up with the lit shader, the ambient pass on the terrain doesn't modulate any textures currently, it simply lays down the ambient color and the lighting passes add on top of that.

Later I'm going to make it so the ambient pass modulates the base texture, but it won't splat. The reason for this is because the ambient pass is there to lay down the z buffer so that subsequent passes get early z-out and don't splat where it isn't needed.

If you want fully lit scene you want to actually use PLSplattingShaderUnlit in your texture mode, though I haven't tested it much.

Shadows are working, it's just that the default sun light has them turned off. Turn them on in EnvironmentGameSystem on the sun light to see, though the sun light might be facing an odd direction currently.

maxxoros

02-07-2006 16:57:47

I set to PLSplattingShaderUnlit in .cfg ,change the ambient light to 1,1,1 make the terrain not white
===
with default ambient light, I enable sun also check cast shadow with object but it still do not work

Could you check the sun function with newest CVS.

Cain

02-07-2006 20:59:04

If I paint a texture on my terrain, on the seams between two pages i don't get the new texture.

See it on the screen below.


Thx for the tip, including dx in the VC++ directories is the better solution.

maxxoros

02-07-2006 21:08:08

Yeah, It is a known bug
http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=1525

Cain

02-07-2006 21:39:59

Oh, so it's a problem of the PLSM2 itself.

Thank you.

Falagard

02-07-2006 21:57:43


Could you check the sun function with newest CVS.


Why don't you check the sun function on the newest CVS? I'm not working on the terrain editing portion right now, and this should be a co-operative effort. Peruse the code and see if you can understand what's going on. Generally there are comments everywhere.

Falagard

06-07-2006 22:17:46

You guys are probably wondering WTF is Falagard doing lately, GOOF sucks. Perhaps you're wondering why I've been so bitchy lately... is Falagard really a woman and it's that time of the month?

Well, I'm in the middle of moving house, so time is a bit tight. However, I *have* been working on GOOF but on things that are fun for me. Fixing bugs? Not so fun at the moment.

On my todo list was to get the environment system working so I had pretty skies, nice shadows, varying time of day, etc. I wasn't completely happy about the previous sky implementation, and had to figure out why I really wanted to do with the environment system.

I want to use skyboxes and transitioning between skybox materials because it's the easiest way for artists to be able to control exactly what color the sky is at any time of the day, but instead of having 24 skyboxes, one for each hour, and transitioning between them, I want to be able to just have a few key skyboxes for dawn, morning, day, dusk, evening and night. Clouds will not end up in the skyboxes in this case, so I needed another solution for clouds.

I had some crazy ideas and put them to the test. One of my problems is that skyplane clouds look so flat, and I haven't seen a very good skydome implementation either. The other problem is that as clouds get further away you actually look at them from the side, so a flat plane looks really fake. I had the idea to create a horizon ring with cloud textures:





Next, I'd add a skydome but not a traditional dome, more like a mushroom shape:





You can see where the sky hemisphere crosses the horizon, so what I'd like to do (if I continue with this approach) is to make it so the dome's verts fade to translucency as they reach the horizon. Haven't done that yet, not sure if I will.



The texture coords on the dome and horizon can be scrolled to have moving clouds.

Then I got to thinking about the old MS Flight Simulator cloud rendering technology - to use actual billboards for clouds. I looked up the old paper, found some interesting things. I also looked deeper into Ogre's BillboardSet functionality and I didn't realize how powerful it actually is.

Now I'm considering attempting to have full sprite based clouds using BillboardSets. I'd write a script for 3ds max to generate the clouds using boxes, same as Flight Sim does, and export the data to xml, then have GOOF load that and create corresponding billboard sets. The interesting thing is that the same thing can be used for Trees. I'm doing something different for Tree leaves currently, but I think it could be adapted to use the same exactly process. Probably not something that those of you want to hear that are using Blender, but it could be possible to write the same sort of exporter for Blender. (I'm not going to do it though).

If trees and clouds were using BillboardSet then they'd work on low spec machines without shaders and you wouldn't have to create two versions of every tree, which is nice.

Clouds will probably require a lot of fancy optimizations, such as a ring of impostors (Tuan knows what I'm talking about here) to get good performance, but I'm not going to do that initially. I think I'd hit up Tuan to work on a ring of impostors anyhow since he's the man :-D




In addition to clouds I've been looking into Ambient Occlusion, Precomputed Radiance Transfer, etc. but that's a different story altogether. AO is cool, gonna use it and integrate it into GOOF eventually for indoor scenes.

OvermindDL1

06-07-2006 22:30:48

There is a game called Cloud Game (free) that has an interesting way of doing clouds. No doubt overkill for what you are doing here, but would be nice as an implementation for when you need to interact or whatever with the clouds. Load up the game, hit tab twice to goto cloud wireframe mode (not full wireframe mode, can't see it then). Each cloud 'piece' is a cylinder (the clouds are on a flat plane, but 3d) as far as interactions go, and the cylinder's attract each other when very close, sticking when they touch. It works very well as an effect, would be nice to interact with as a craft or whatever could push away the clouds as they go through them, and the calculations are quite fast since it is a flat plane in the sky. You could have multiple flat planes as different layers for different clouds types/heights as well.

Falagard

06-07-2006 22:39:56

Thanks, but that does look like overkill. Neat though.

OvermindDL1

06-07-2006 23:10:19

Useful if you need interactable clouds.

Falagard

06-07-2006 23:31:40

Ya, but I don't :-D I've played that game before when it first came out. They created another game, Flash or Shockwave based that was pretty awesome too - you're a small organism in water and have to evolve to eventually become the biggest predator through multiple levels of progressively harder creatures.

ghostlake

07-07-2006 03:13:18

Look so cool... I am so busy this time to look more into GOOF :oops: :oops: :cry: ... damn the boss 8) :D
===
Btw, dynamic cloud is a good ideal but in most case it will not so necessary :)...but a good feature an engine
===
PS:

You guys are probably wondering WTF is Falagard doing lately, GOOF sucks. Perhaps you're wondering why I've been so bitchy lately... is Falagard really a woman and it's that time of the month?

Falagard

07-07-2006 04:43:44

Ya, I know it's not necessary, however I really want good looking skies.

I'm going to guess that when outdoors around 30% of the screen is filled with sky most of the time. I think that dynamic clouds are overkill really, but I haven't achieved a good enough looking result with just skyplane and skydome, however that might just be my artistic ability.

I put together those cloud textures myself and it took a full night ;-)

ghostlake

07-07-2006 06:16:28

Any game artist could make their own cylinder, :D, make it big enogh to cover all the scene and create texture, animate it with material script :D .... But for some one like level maker ... this will be great help

Falagard

07-07-2006 06:38:45

You lost me there a little, but anyhow I've decided to go with built in skydome in Ogre and use cylinder for horizon and am happy with the results. I won't be pursuing sprite clouds any further.

However, I may still look into writing that MaxScript exporter for camera oriented billboards for the tree leaves and other plants.

jacmoe

07-07-2006 12:52:40

Falagard: you're crazy, raving mad! A one man army. I am staying tuned! :)

Cain

08-07-2006 13:29:59

Found inconsistencies:
Is it correct, that GOOFEditorSystemContainer.h is in the sourcetree (include) of GOOFCommon? I would expect it in the tree of GOOFEdSystem.

Also the file GOOFEditorSystemContainer.cpp in the tree of COOFCommon looks weird for me. It's not including GOOFEditorSystemContainer.h, but GOOFGameSystemManager.h and has different implementations for methods of GOOFGameSystemManager, than GOOFGameSystemManager.cpp.

Possible solution:

I think since GOOFEditorSystemContainer.h is meant as an abstract class (the methods have a =0 in their definition) we can get rid of GOOFGameSystemManager.cpp and move GOOFEditorSystemContainer.h in the tree of GOOFEdSystem.

I haven't tried that yet!!! Don't know if it works!!! I'm waiting for Falagard, to give a comment before.

Falagard

10-07-2006 17:05:16

Thanks, GOOFEditorSystemContainer.h should be in the GOOFEdSystem project, and GOOFEditorSystemContainer.cpp is not needed, it is a rogue file that isn't included in any projects so should be deleted.

I'll make these changes.

singotos

17-07-2006 18:57:27

Are there any good news ... :) ... Seem so long we dont see any info/update from you. Falagard, for the first release :roll: :roll: :roll:

Falagard

17-07-2006 20:32:40

Don't hold your breath, I'm working on the messaging, threading and physics systems all at the same time and I expect this major update to take quite a while.

Cain

19-07-2006 08:50:58

I'm working on a Networking and GameState Environment.
I inherited GameSystems into these, but it's not looking quite harmonic for me yet.
I tried to add you in ICQ Falagard, but 'till now got no autorisation.
I'd like to have a talk with you, to keep things in sync with your GOOF-Environment.
So it would be as compatible as possible and reuseable for other users.

Falagard

19-07-2006 15:24:48

I just authorized your ICQ request, I don't run ICQ at all times but I'll try to be on.

Can you clarify what you mean by GameState?

Feel free to post here as well.

I've talked myself out of working on a full messaging system and multithreaded system for now, so what I'll be working on instead is physics and networking running on the main thread and all game systems there as well.

bibiteinfo

21-07-2006 03:34:13

Falagard, I'Ve developp a pathfinding for my stage at school based on this article. http://www.gamasutra.com/features/20020405/smith_01.htm
(You need to be freely registrer to see it)

If you are interested, I can put it in GOOF. The only bad thing is that I don't know Ogre a lot. I find Ogre at the end of my stage so the pathfinding is on my own rustic graphic engine. For the graphic engine, this is not a problem because the pathfinding part is graphic independant. The only thing that my pathfinding is dependant is the terrain. So the port to do will be from my terrain to PLSM2.

Well you are telling that you are doing the physic, so I might wait you finish the physic and then with the physic detection collision and data put my pathfinding.

Falagard

21-07-2006 04:18:37

Nice! Just a few days ago I was looking at various AI libraries such as the RenderWare AI solution, FEAR AI framework, and OpenSteer. RenderWare seemed to have a pretty awesome polygon soup analysis system to determine path waypoints and connect them into a graph. OpenSteer looked pretty capable as well for certain tasks. I was surprised at how cool their demo was with obstacle and entity avoidance, etc.

I'd love to see what you've come up with.

I'm doing physics but probably not going to do it using messages now. I've talked myself out of using messages for all the systems and instead go with an easier approach for now. At the moment I'm looking closely at OgreNewt and trying to figure out how I can start implementing GameObjects to wrap physics entities such as bodies, collisions and joints.

jacmoe

21-07-2006 14:58:57

Don't forget MicroPather - made by the tinyxml 'team'.
More game-oriented than OpenSteer.
In fact, I think OpenSteer and MicroPather could cooperate in a solid pathfinding solution. :wink:

fusukery

03-08-2006 19:33:48

The thread is going to the second page .... :(
===
The new PLS2 has been release, so a new update of GOOF would be available soon ?

Falagard

03-08-2006 23:57:59

I've been moving, just got internet back today. I've started working on integrating physics (OgreNewt) as game objects.

Clay

Falagard

07-08-2006 20:41:39

Bleck. I am integrating physics into GOOF, but my first task was to take Newton's low level collision system and replace my existing Opcode system (actually, not really replace, but provide an additional alternative). The theory here was that I'd just be able to swap them out.

Unfortunately, I quickly had them swapped but I was unable to get Newton't ray collision code working even though it should have been pretty straightforward. I'm not sure what I was doing wrong, but I've abandoned it because I don't feel like fighting with it. Instead I'm going to keep Opcode in.

Really, the low level collision stuff is used by the editor for precise my picking, and also by games that don't need physics but need collision detection.

The reason why I wanted to have a Newton collision detection game system (in addition to the Opcode collision game system) is because if you're using physics and Newton already it'd make sense to use Newton's collision detection library instead of an additional library. However, at the same time, there's a completely different way of doing ray casting that isn't low level with Newton - which is to use the physics API for raycasting.

So for now, I'm stopping my work on the collision game system stuff and moving back into writing the Physics game system for Newton. I thought the collision detection would take a day, two tops, but since it has taken 3 or 4 I'm just going to ditch it.

Clay

Falagard

08-08-2006 05:58:37

Nevermind, figured out the Newton collision stuff. This makes me very happy, because I really wanted to get it working. I already had my collision game system sharing collision shapes, and I read in the Newton docs that Newton collisions can be shared amongst bodies, so this works out perfectly.

So now I have both Opcode and Newton working for ray cast and shape to shape collisions, however Newton doesn't support scale transformations.

Falagard

17-08-2006 06:09:07

Okay, still slowly working away at physics.

http://www.larabie.net/ogre/GOOFPhysics.wmv

What you see here is several bodies + collision shapes, the ability to edit shape size, type and mass right in the editor, and the "start simulation" button starts the physics simulation and then stops it when it's clicked a second time.

It's nowhere near complete and not yet in CVS but thought you should see some progress. There was some strange interpenetration between the bodies there, and obviously you can tell they're not colliding yet with terrain - but hey, like I said, it's a work in progress.

Why physics? I'm planning two types of character control mechanics - physics based control (using forces to move a character around) and direct collision detection handling (manually sliding along walls, etc).

Those two should handle the majority of character based games such as first person shooters, rpgs, adventure games. Having physics in an engine in general is useful for many types of games as well.

Clay

bibiteinfo

17-08-2006 17:14:30

The video show great promises! I Hope to see it soon in the CVS!

Continue your great job.

ghostlake

18-08-2006 03:39:39

WOW, promising :)
===
Looking to see it on CVS soon. After a long time, the next CVS of GOOF must be a great update :)

Falagard

21-08-2006 06:57:08

Started porting the GOOF editor to wxWindows. People don't seem to take a project like an editor seriously unless the GUI looks pretty. Actually, the real reason is usability - a tool like an editor should be very usable. Things you take for granted, such as copy/paste in text boxes, tabbing through controls, right click to copy/paste text, etc. should "just work" and they don't by default in CEGUI.

I have made progress and have Ogre rendering in a custom wxWidget control. The wxOgre example in the wiki was severely broken and not implemented properly anyhow. I'm not knocking the original author, it's just that it was done in a way that only worked on MS Windows, had a lot of unnecessary code, and not done in the way that you should subclass an existing control like wxControl.

I also have it integrated with the wxAUI toolkit http://www.kirix.com/community/wxaui/screenshots.html and it seems to work nicely. I'll let you know when I have it finished ported, it'll take me a week or so.

pjcast

21-08-2006 08:35:54

Wow, that is good news :)

I tried my hand before with an editor in CEGUI, but found it was pretty difficult to get a clean looking interface with minimal effort (CEGUI is awesome, but not in this regard - unless you have a full time artist making a slick skin). I also tried the wxOgre example with little luck, and hence gave up and moved to C# - if I had had more luck with wxWidgets, I would have used it in a heart beat. However, I look forward to seeing your editor outside of the Ogre window as it were, and good luck with it :)

Dale_ee

31-08-2006 13:14:06

Hi!
I very appreciate the job done by Falagard. It's awesome!
But I had to spend about 6 hours just to compile and run GOOFed.
Here are some common mistakes that took place during my install.

1. Do not forget to rename resources_GOOF.cfg to resources.cfg in samples\common\bin\debug folder
2. I've tried to compile Release at first. Dont do it! :)
3. Add "Plugin=Plugin_PagingLandScapeSceneManager2" in your plugins.cfg file if it's absent.
4. In my case somehow "Samples\Media\GOOF\Objects\Meshes\Trees\GeneratedLeaves\" folder wasn't present. Create it yourself, if you don't have it either.
5. Some projects won't compile if u don't have proper paths for DX libraries. Correct it.
6. If something goes wrong and *.log files are silent about this, check if you linked RIGTH libraries. In this case all libraries' version that are present in our solution must be debug. for example "OIS_static_d.lib" and so on. But only those, that we build ourselves.

Well. That's almost all that I remember.

Falagard

31-08-2006 16:21:40

Thanks Dale,

I'm going to be updating CVS once I'm finished my latest round of changes and providing all the dependencies precompiled and as a zip for Visual Studio 7.1 and 8.0 so that setting up GOOF will be reduced to just a few steps.

Thanks for your patience and for your tips.

I'm porting the editor to wxWidgets and things are coming along fine. I'm still working on the actual editor framework which handles things like automatically showing/hiding toolbars, windows and menus as you switch between tools, and then I have to starting porting the two tools over as well... it's taking longer than I expected but will be worth it.

Regards,

Clay

Dale_ee

31-08-2006 16:40:47

Are there any news on landscape painting bug, when tile borders stood unpainted?

Falagard

31-08-2006 17:12:52

No news from me, that's something that Tuan will have to address since it's inherent in the PLM2 scene manager. It might have already been fixed though I don't think so. I haven't touched the terrain editing plugin for a while now.

PatrickB3

31-08-2006 19:02:37

I would say it is not fixed as I'm using latest CVS and it's still there.

Falagard

31-08-2006 19:16:59

Ya, I didn't think it was fixed. Go pester Tuan about it - he last mentioned that it was probably something to do with the fact that he added code for scaling the splatting texture at a different res than the terrain heightmap.

tuan kuranes

31-08-2006 21:07:27

@Bug reporters hidden deep inside GOOF threads : Please make a new thread, a single subject/task per thread is easier to follow for me, specially when I lack time. Describe the problem again and even better try to find exaclty what texturemode/Vertex shaders (compression, morphing) combination make it happen or not.

@Falagard : a 22 pages thread, that's the sign. Time to ask Sinbad for a dedicated forum, no ? ;)

Falagard

31-08-2006 21:08:51

Hehe, are you getting fed up? :-D

Yes, I'll be asking Sinbad for my own forum soon.

tuan kuranes

31-08-2006 21:11:37

;) I'm jaleous : 45329 views on your single thread, It may be more than whole plsm2 thread views summed :shock:

Falagard

02-09-2006 06:40:41

Quick update showing screenshot of wxWidgets interface. Looks simple but a lot going on here... stuff that most people don't care about except for tool creators. Windows and toolbars can be "docked" the sides, top and bottom of the app.
You register tool plugins with the editor, and each tool registers a set of toolbars, windows and menus for that particular tool. The editor automagically manages these things - so when the user switches to a different tool, it'll remove the previously active tool's windows, toolbars and menus and add the newly activated tool's GUI. It also saves the positions of all windows and what they are docked to on a per tool basis, so when you switch between tools everything looks the way you left it. A View->Windows menu is automatically created and handles showing/hiding windows.

The main window that houses Ogre resizes the viewport and maintains aspect ratio as windows are docked around it.



I'm finished the editor framework which now uses wxWidgets and am in the middle of porting the GOOF engine editor tool.

duff

02-09-2006 09:56:52

so good news ;)

praetor

03-09-2006 04:32:48

Excellent work Falagard. It's looking quite good.

Check your PMs, I have a question for you.

duff

03-09-2006 11:04:17

is it possible to change view and have 4 views (xy, yz, xz, 3D).
Or switch quickely between this type of view?

Shadow007

03-09-2006 12:14:56

to tell that although I don't post, please keep going, telling us of your progress ... And keep up the Marvelous work !

bibiteinfo

03-09-2006 17:41:42

It now look like a real serious editor! It was good for programmers, but maybe confusing for artist :) Continue you're good work Fala :)

Falagard

03-09-2006 18:20:40


is it possible to change view and have 4 views (xy, yz, xz, 3D).
Or switch quickely between this type of view?


I plan to support quickly changing between 2 cameras and you can set them up to any view you want. I've found while working on a program called MyVirtualHome that this can be very intuitive and easy to use. At times you sometimes wish you could have two viewports visible at once but toggling quickly between two can get similar results.

Thanks for the support - it keeps me motivated!

jacmoe

03-09-2006 21:27:16

Very inspirational! Looking forward to seeing this arriving in a CVS repository near my computer! :wink:

I appreciate the amount of work you've put behind the decievingly innocent looking editor! :)

ghostlake

05-09-2006 14:29:25

Awesome work, Falagard, It look like an Editor now.... :). Replace CeGUI is a good news... It s not familiar with something like editor and the speed of cegui is still bad :roll: :roll:
===
Seem a lot of Update, I hope that the editor could be something "official Ogre Editor" :D :D :D :wink:

bibiteinfo

06-09-2006 00:16:30


Seem a lot of Update, I hope that the editor could be something "official Ogre Editor" :D :D :D :wink:


Yep, but it still need a lot of work and to achieve something like an "official Ogre Editor" Fala will need help, he can't do everything alone!

GenericBum

07-09-2006 07:09:05

Nice work on GOOF! I've been working with Ogre for quite a while and I can't believe I didn't look at this project sooner.

Thanks,
GenericBum

giulian2003

17-09-2006 11:06:38

Hello everybody,

First of all, a big THANKS to Falagard for the grat work he is doing!

Just wanted to add my little contribution to this project :)

Following the instructions found at http://www.ogre3d.org/wiki/index.php/Game_Object_Oriented_Framework_Installation i managed to compile GOOFEd in Release version using Visual Studio 2005 :) Here are some problems i run into:

1. Plugin_OctreeSceneManager is a requirement (it will make GOOFED.exe, but it will crash without it), but its not a subproject of GOOFEd, i had to compile it from the Ogre_vc8 project.

2. I couldn't find the boost lib, i had to add un additional library path to Visual Studio: "G:\DEV_ROOT\Boost\bin\boost\libs\filesystem\build\libboost_filesystem.lib\vc-8_0\release\threading-multi"

3. The dependencies all all wrong, i had to compile alot of subprojects first before acctually compiling GOOFEd subproject.

4. I needed to rename paginglandscape2_GOOF.cfg to paginglandscape2.cfg and resources_GOOF.cfg to resources.cfg in
"G:\DEV_ROOT\ogrenew\Samples\Common\bin\Release"

5. I needed to create the "GeneratedLeaves" directory in
"G:\DEV_ROOT\ogrenew\Samples\Media\GOOF\Objects\Meshes\Trees"

Other then this everything went smooth, Visual Studio converted the GOOF.sln from 7.1 to 8.0 without complaining.

Falagard

17-09-2006 14:47:24

Thanks for the tips, Giulian. If you'd like to update the wiki with any additional info on installing GOOF, feel free.

I realize the project dependencies are all messed up and the projects don't compile in the correct order, that's something I need to fix still.

The GeneratedLeaves folder I think happens because the folder is empty in CVS and therefore is assumed to be not needed and doesn't get created by CVS when you do a checkout.

bibiteinfo

19-09-2006 04:13:57

Congrats Fala for your MVP badge!!

Falagard

19-09-2006 04:43:29

Thanks :-)

Clay

20-09-2006 00:23:26

Indeed it's well deserved.

Is there a binary version of the Goof editor we can play with or should I be building it from source?

bibiteinfo

20-09-2006 03:34:04

There is no exe since it's still in developpement, Fala told that it would have a binary version when it reach alpha version minimum.

So built it from source :)

pkdawson

21-09-2006 11:02:19

The source build process is a bit overwhelming, and as giulian2003 says, there are a number of necessary steps that aren't documented. It'd be great if someone would provide some unofficial SDK and editor binary snapshots.

bibiteinfo

21-09-2006 16:13:56

I think a SDK is kind of too soon. There is a lot of things missing so it's not usable right now for developpement. Maybe a all in one working solution would be needed.

I will release an exe, for demo purpose.

jacmoe

21-09-2006 19:56:13

The source build process is a bit overwhelming, and as giulian2003 says, there are a number of necessary steps that aren't documented. It'd be great if someone would provide some unofficial SDK and editor binary snapshots.
No way, mate! No way! :)

I think Falagard is not providing such a thing on purpose: GOOF is in alpha and if you cannot compile a pile of libraries after setting them up, this is not for you. :wink:

pkdawson

25-09-2006 13:52:09

I think Falagard is not providing such a thing on purpose: GOOF is in alpha and if you cannot compile a pile of libraries after setting them up, this is not for you. :wink:
I have no problem compiling the libraries. It's GOOFEd that doesn't work because of missing files/instructions. It's mostly the need to dedicate >2GB of space to compile GOOF and its dependencies that makes me want binary snapshots :)

Falagard

25-09-2006 15:13:25

What are the errors/problems?

First suggestion: compile multiple times. The dependencies are out of order, so for example, one project might rely on another project to link, but the second project hasn't compiled yet.

The only other (minor) problem could be issues with duplicate materials. There have been multiple posts here on how to resolve that if it exists - do a search for the file in question and you'll see the fix.

OvermindDL1

25-09-2006 18:17:43

Two gigs? That is all GOOF takes? Bah, try compiling some decently large libraries, one I have takes over 12 gigs in intermediate files, and 2 gigs when cleaned...

But yea, the dependencies really need to be fixed, I tried to compile GOOF a few weeks ago and had to fix it manually...

giulian2003

29-09-2006 11:38:57

After considering other game engines/frameworks i've decided to use GOOF.

Just curious: is there some kind of roadmap for this project, i mean a list of what classes are finished, what are in development ... ?

Also, is there a list of design decisions, and maybe coding conventions? I am asking because i was thinking to help coding some missing parts ...

bibiteinfo

29-09-2006 23:13:01

For the design and the project advancement, there is just the wiki.
http://www.ogre3d.org/wiki/index.php/Game_Object_Oriented_Framework

The informations are a bit out of date.


For the coding convention, it should be the same as the Ogre one.
http://www.ogre3d.org/phpBB2/viewtopic.php?t=5818

It's a bit hardish to help right now, as long as there is no road plan and section written by Falagard as : To be Done.

One thing Falagard already asked is a third person camera.

In the recent post, he shows us the new GUI for the editor. He's working on the physic too.

And me I've started implementing my pathfinding in GOOF ( Nothing working for now )

giulian2003

30-09-2006 01:36:17

ok, i'll look into a 3rd person cameras then ...

Falagard

30-09-2006 02:05:38

Yeah, I'm currently hard at work on the core engine, as the editor is nearly complete. The major feature I need to add for the editor is the ability to add new object definitions without needing to go through text files, but I'm a bit burned out on the editor part so I'm taking a break and working on one of the biggest engine features that needs some work: handling meshes.

Basically I'm reworking the MeshGameObject class completely so it's more viable for large worlds.

As far as features go before I release alpha, the list is still sorta large.

1. Finish the physics system so that it can be used for character movement.
2. An attachment system to be able to specify attachment locations on an object and attach any other object to it.
3. Mesh animation, animation blending, animation sharing between objects.
4. Character class which plays animations based on current state (movement direction, velocity, jumping, strafing, etc.)
5. Redo the mesh system (in progress). This is a biggy and involves a lot crazy stuff that is too complex to explain in bullet point. Basically, will be using all of Ogre's advanced features for mesh lods, material lods, etc. but also tie into background resource loading, load only the lods that are necessary, track which lods are currently loaded, etc.
6. Ability to add, update and delete meta objects from the editor using property dialog functionality. Once a meta object is updated, call a function on all objects that use that meta data so they can update themselves with newest data.
7. Managed material system
8. Create plugins of all dlls and dynamically load.
9. Create a viewer application that is separate from the editor and can load any world file.
10. Update the lighting system, particle system, to use new fading code based on updated mesh code

Those are my major todos, once finished and tested I release alpha. I will likely update CVS after I get the meta objects finished though. I may also fit in the vegetation system before I release alpha. How long will the above list take? Based on my current speed of development, 3 months.

I have a core list of features that I think are necessary for an engine, and they include:

1. Physics simulation, character movement, vehicles, damage, explosions, breakable objects
2. Lighting - ambient occlusion, realtime lighting and shadows. Lighting manager is required to control ambient, shadows when moving from interior to exterior
3. Trees and vegetation
4. Dynamic environment. Sky transitioning, clouds, fog, global ambient, sun position and direction, sun glare, dynamic shadows
5. Networking using ReplicaNet. Run GOOF engine in server mode where it doesn't initialize any rendering systems. Update all objects to know whether they're being created on standalone server or not.
6. Sound management, 2d sounds, 3d sounds, sound line, background music.
7. Doors, triggers, elevators
8. In-game cutscenes
9. Background loading, resource garbage collection, forced loading
10. AI framework
11. Character inventory, equipping with 3 clothing types: shared skeleton, individual skeleton, attached to bone
12. Terrain with splatting

The above will take me years unless I have help :-)

Falagard

30-09-2006 02:16:43

Oh yeah, the editor is very nice now, in my opinion.

Not only did I port to wxWidgets, I fixed and added a lot of general features to the GOOF Engine Editor Tool (the tool for creating scenes for the GOOF engine).

1. Multi select objects from the selection dialog
2. Ctrl drag to box select objects in the viewport, or Alt drag to box unselect, with selection lines to show what you're selecting.
3. Option to orient objects to the normal of the collided object when in drag mode. Means you can basically drag things up walls now if you're in a room and the object, such as a painting, will orient to the wall you drag it along.
4. Redid the movement axis manipulator so it now moves to exactly where you want it to move to instead of sliding along crazily.
5. Added a line that shows what you're linking to when you are in link mode.
6. Tree view for the select dialog, with scene hierarchy
7. Ability to click and edit partition properties from the same select dialog, and shows objects under their partition with the active partition listed at the top.
8. Obviously, all the wxWidgets stuff such as window snapping, toolbar, menu, automatic viewport resizing, view menu which lists windows, redid all the open/save functionality to support a standard file dialog, etc.

Fixed tons of bugs. Undo system works now. Linking and unlinking objects fixed. Deleting multiple objects fixed when there are parent/child relationships between objects. The movement axis manipulator fixed. Fixed dragging over other objects - the object used to jump around crazily.

Probably tons more as well, but this is what I remember off the top of my head.

bibiteinfo

30-09-2006 02:40:24

Woaaa this is a big list!!! Continue like that!!

With the next release Fala, you should ask you're forum and then rewrite this list and make a call for help and when someone wish to add the feature, you detail explain it and say where in the design it should go.

giulian2003

30-09-2006 10:37:52

I am willing to help ... was looking trough the list of features you want to realease before alpha and i was wondering what can be done that doesn't depend too much on the things you're currently updating: maybe the 2. or 7. ? Care to elaborate on any of those, i mean the basic ideea behind them, how would you like to implement them, etc ... that way maybe i could do the coding stuff.

Harvest

01-10-2006 13:52:31

I compiled GOOF under Windows VS2005 yesterday and it worked fine - but shouldn't the command in the InstallationWiki->Boost->9. be "bjam.exe -sTOOLS=vc-7_1 (or vc-8_0 for vs2005) --with-thread --with-filesystem INSTALL ? Didn't get any libraries installed before writing "install" behind that command.
Maybe I try to compile it under linux by the end of this month. If I succeed, I'll post it here.

I have a little question concerning sound. It isn't yet implented, is it? Will GOOF use openAL as well for music? A while ago, I played a bit with AL, but getting an ogg stream playing without eating all my resources, was not possible to me..

Has anybody already used GOOF parts in one's game? Is it already possible to create something like this tutorial here:
http://www.ogre3d.org/wiki/index.php/Pr ... pplication ?
The absolute-minimum-code application, so that you keep things simple for a better understanding of the engine's functions. It's difficult to me finding out where to start. Just reading code and trying to understand for now..

bibiteinfo

01-10-2006 17:40:03

For now no, because it is before-alpha. There is a need for documentation, but GOOF should be finish before doing documentation. The reason is that if you write documentation and the Engine modify, it's a big waste of time. The best example for this is the interface that has completly change compare to the version on the CVS. If I would have done a tutorial on how to use the editor, I would have to change almost everything.

So like I say GOOF is under heavy development, so there is no game using it for now, and there is no absolute-minimum-code for using it.

duff

17-10-2006 09:57:22

any news about this beautiful project?

Falagard

17-10-2006 17:07:04

Nothing really drastic for news. I'm working on the Mesh functionality - which is one of the most important pieces. It's taking a lot of time and is dull work.

What I've done is tested with 2000 objects per partition to see how fast the loading was going, and it turned out it would freeze up for about a second while attempting to instantiate that many objects when a Partition was close enough to be loaded, and ditto when a partition was unloaded. To fix this I've implemented delayed instantiation and destruction of objects so that it creates as many objects as it can in X number of milliseconds and if it exceeds the milliseconds it then waits till the next frame. This has fixed the problem, works like a charm.

I also created a LODManager system so any object can have its own LODManager that handles it's level of detail. Useful later on for physics, and for objects that need special handling.

Now I'm banging my head against static geometry loading.

SexinzerO

19-10-2006 16:17:53

I get GOOF from CVS this time OGRE_SDK1.2.3 .net 2003
complie and run error



how should I do?

SexinzerO

19-10-2006 16:20:59

I only want to use terran edit and splat texture by PLSM.

What easy way for me?

Falagard

19-10-2006 19:36:40

Try debugging it and find out where the error occurs ;-)

SexinzerO

19-10-2006 19:42:03

debugging is very hard for me. Y_Y

SexinzerO

19-10-2006 20:57:56

in GOOFAplication.cpp
---------------------------------------------------------------------

void Application::go()
{

if (!setup())
return;

error in this line------->>> mRoot->startRendering();

}
------------------------------------------------------------------------

Y_Y how should i do?.

Falagard

19-10-2006 21:12:26

Lol, well did you try going further into startRendering to find out what the problem is?

Check the ogre.log file?

I can't help you with so little information, startRendering is not enough.

I'm afraid that perhaps you've tried to use GOOF while it's too early - especially for someone who isn't familiar with debugging. GOOF in it's current state isn't ready for people who aren't able to dig deep into the code to find out why something is broken - it's not released as stable code at the moment, it's a work in progress.

SexinzerO

19-10-2006 23:13:52

logfile
http://web.thaicool.com/loveless/ogrelog.txt

I ever complie and run GOOFed is working.
but when I update in this time OGRE_SDK and GOOF from CVS runtime error.

I forgot backup GOOFed When it working. I am newbie Y_Y

SexinzerO

19-10-2006 23:21:55

I only want to use terran edit and texture splatting.
Have a easy way for me?




sorry for your time Y_Y........

Falagard

20-10-2006 01:25:26

No I can't help you beyond give you suggestions.

Rebuild GOOF completely - I'm guessing it's a DLL problem.

SexinzerO

20-10-2006 08:46:53

I rebuild GOOF about 30 time.
all error same this problem .

I wait for Complete GOOF is best for me. :cry:

hmoraldo

23-11-2006 20:03:24

Hey Falagard,

I'm trying to compile GOOF in Linux. The code will need a lot of small modifications to work here. As soon as I get the code working here, I'll try to give some hints of how to get that done, for other future Linux users of GOOF.

I've already compiled some of the core GOOF libraries, but I won't be happy until I don't get the GOOFEd working.

Regards!

Falagard

23-11-2006 21:08:12

Nice!

hmoraldo

23-11-2006 23:17:02

Thank you!

I'm working on it... I'm only having problems with GOOFPagingLandscapeDecalGameObject.cpp, as I can't see the way it can work. The constructor of PagingLandscapeDecalGameObject calls a constructor in PlaceHolderGameObject with four parameters, while it never takes more than three... changeLODFinalize refers to a lot of class members that aren't defined anywhere, not in that class nor in base classes; I can't see how the code in that file could compile in any other platform. I suspect it's the code of a half-update or something like that (i downloaded that from cvs); I'm ignoring it for now but if you have any interesting comments about it please tell me.

So, I keep working...

Regards,

Falagard

24-11-2006 02:16:15

Remove that file completely, it was something I started and didn't finish. In the vcproj it is flagged to not be included in the build, so the project compiles fine, but in your case you can just remove it.

hmoraldo

24-11-2006 03:07:06

Thank you!

hmoraldo

24-11-2006 04:02:10

Well, I kept trying to make GOOF work in linux.

Code needed a lot of small changes, as GCC doesn't like many non-standard features that are valid in VC++.

I've been trying to make this work with Scons... and had only partial success. After some hours of 'porting' I got the full code to compile well, so that I had all separate libraries working. But I couldn't make them link together, so it seems I did one or more mistakes in the process... I'll be back on that problem tomorrow afternoon (it's at night here now), or on monday morning I guess.

But my work today made me clear about something: a code port for Linux is obviously possible, and I think in the future it would be great to keep a Linux distro of GOOF as well as the Windows one. But it won't be effortless to get to that point I guess.

This will probably take me some more days until I get this done (also I have some other duties here, but I'm enjoying a lot this one), but I suppose I will as soon as I can.

(The ironic thing is: I haven't tested GOOF yet... and probably won't until I get the Linux version working ok... but from what I heard and saw until now about it, it surely looks promising, and the code is huge and very professional as well)

Best regards!

nickdan

24-11-2006 08:26:11

Hi,

I'm a Linux developper also, so I wcan help with that point.
Up to now, I'm new with Ogre, s first, I'm doing the tutorial to learn it.
Then, when I will be "fluent" with it enought to me, I will study GOOF. I read all the 25 pages of this topic (it was long, but full of informations), and I'm also very interested in it, and Falagard, only one word : you're impressive, very impressive.

So I will try to compile it, and see the differnces too, as hmoraldo.
I'm using KDevelop also, so prehaps I will make some tutos for it if some are interested.

@hmoarldo, I will ask you when I will start to see GOOF compilation to see what you have already done with it, if your modifications will not be already integrated.
@Falagard : so a question : if we have made changes to your code to make it compatible with Linux/GCC/..., how can we send you our modifs to be integrated ?

NOTE : it is possible, in a near future that I acquire also a MacOSX computer, so I will try also with it... ;)

hmoraldo

24-11-2006 12:14:10

@hmoarldo, I will ask you when I will start to see GOOF compilation to see what you have already done with it, if your modifications will not be already integrated.

Sure. I'm less fluent in Linux as a developer than I am in Windows, and it's my first time using Scons... but I think I'll have something ready soon.

@Falagard : so a question : if we have made changes to your code to make it compatible with Linux/GCC/..., how can we send you our modifs to be integrated ?

This is an interesting question... I think I'll be writing some pointers for code modification first, for those who want to test GOOF in Linux, until somehow we get those into the cvs.

NOTE : it is possible, in a near future that I acquire also a MacOSX computer, so I will try also with it... ;)

Hey, that would be great!

Best regards,

hmoraldo

24-11-2006 16:46:59

Well, I got a first program using only GOFFCore, GOFFCommon and GOFFAppFramework to fully compile with scons in Linux. And I can run it, but it segfaults a little after selecting the video mode (actually... it's segfaulting the same even with some Ogre sample apps; I don't think it's a problem in my 'port').

Scons, when run for compilation, detects the correct libraries are already installed, and prints errors when they are not. But the library paths need to be configured somehow first (those in the scripts are the ones in my Ubuntu system).

The SConstruct script, for those that are curious (as it's still useless without a lot of small patches in the code, and some extra stuff):

listinc=[
# just for thist test
'.',

# location of ogre includes
'/usr/local/include/OGRE',
# location of boost includes
'/usr/include',
# location of cegui includes
'/usr/local/include/CEGUI',
# location of ois includes
'/usr/local/include/OIS',
# location of noise includes
'noise/include',

# location of both paging landscape includes
# (you'll need to install paginglandscape so that directories coincide)
'paginglandscape/PlugIns/PagingLandScape2/include',
'paginglandscape/Tools/MapSplitter/include',

# location of opcode includes
'opcode',

# location of all the goof includes
'GOOFAppFramework/include',
'GOOFCommon/include',
'GOOFCore/include',
'GOOFEd/include',
'GOOFEdPlugins/include',
'GOOFEdPlugins/GOOFGameObjectEditorPlugin/include',
'GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/include',
'GOOFEdSystem/include',
'GOOFExtension/include',
'GOOFGameSystems/include',
'GOOFGameSystems/GOOFOpcodeCollisionGameSystem/include',
'GOOFGameSystems/GOOFImpostorGameSystem/include',
'GOOFGameSystems/GOOFResourceBackgroundGroupGameSystem/include',
'GOOFGameSystems/GOOFEnvironmentGameSystem/include'
]
env=Environment(CPPPATH=listinc, LIBPATH='.')


# check for required include files and libraries
conf = Configure(env)
if not conf.CheckCXXHeader('Ogre.h'):
print 'Ogre must be installed!'
Exit(1)
if not conf.CheckLib('OgreMain'):
print 'OgreMain library must be in path'
Exit(1)
if not conf.CheckLib('OgrePlatform'):
print 'OgrePlatform library must be in path'
Exit(1)
if not conf.CheckCXXHeader('CEGUIBase.h'):
print 'CEGUI must be installed!'
Exit(1)
if not conf.CheckLib('CEGUIBase'):
print 'CEGUIBase library must be in path'
Exit(1)
if not conf.CheckLib('CEGUIOgreRenderer'):
print 'CEGUIOgreRenderer library must be in path'
Exit(1)
if not conf.CheckCXXHeader('OISPrereqs.h'):
print 'OIS must be installed!'
Exit(1)
if not conf.CheckLib('OIS'):
print 'OIS library must be in path'
Exit(1)
if not conf.CheckCXXHeader('OgrePagingLandScapeOptions.h'):
print 'Paging Landscape files should be in paginglandscape directory!'
Exit(1)
if not conf.CheckCXXHeader('Opcode.h'):
print 'Opcode should be in opcode directory! (and remember to modify the opcode files as asked in the wiki)'
Exit(1)
if not conf.CheckLib('Opcode'):
print 'Opcode library must be in path'
Exit(1)
if not conf.CheckCXXHeader('boost/version.hpp'):
print 'Boost must be installed!'
Exit(1)
if not conf.CheckCXXHeader('boost/filesystem/fstream.hpp'):
print 'Boost/filesystem must be installed!'
Exit(1)
if not conf.CheckLib('boost_filesystem'):
print 'boost_filesystem library must be in path'
Exit(1)
if not conf.CheckCXXHeader('noise/noise.h'):
print 'Libnoise files should be in noise directory! (and also move noise/include/* files to noise/include/noise/*)'
Exit(1)
if not conf.CheckLib('noise'):
print 'noise library must be in path'
Exit(1)
if not conf.CheckLib('paginglandscape2'):
print 'paginglandscape2 library must be in path'
Exit(1)


# list of files needed for compiling the GOOF App Framework
goof_appframework_list=Split("""
GOOFAppFramework/src/GOOFApplication.cpp
GOOFAppFramework/src/GOOFInterfaceManager.cpp
GOOFAppFramework/src/GOOFInterfaceScreen.cpp
""")

# list of files needed for compiling the GOOF Core
goof_core_list=Split("""
GOOFCore/src/GOOFCoreGameObjectManager.cpp
GOOFCore/src/GOOFCoreGameObject.cpp
GOOFCore/src/GOOFCorePartition.cpp
GOOFCore/src/GOOFCorePartitionManager.cpp
GOOFCore/src/GOOFFullSceneOperation.cpp
""")

# list of files needed for compiling the GOOF Common
goof_common_list=Split("""
GOOFCommon/src/GOOFAxisManipulator.cpp
GOOFCommon/src/GOOFCollisionGameSystem.cpp
GOOFCommon/src/GOOFDataFileResource.cpp
GOOFCommon/src/GOOFDataFileResourceManager.cpp
GOOFCommon/src/GOOFDragManipulator.cpp
GOOFCommon/src/GOOFFreeCamInputController.cpp
GOOFCommon/src/GOOFGameObjectFactoryManager.cpp
GOOFCommon/src/GOOFGameSystemManager.cpp
GOOFCommon/src/GOOFGenericUtils.cpp
GOOFCommon/src/GOOFInputListener.cpp
GOOFCommon/src/GOOFLine3D.cpp
GOOFCommon/src/GOOFMessageWindow.cpp
GOOFCommon/src/GOOFOperationManager.cpp
GOOFCommon/src/GOOFOverheadCamInputController.cpp
GOOFCommon/src/GOOFProperty.cpp
GOOFCommon/src/GOOFPropertyContainer.cpp
GOOFCommon/src/GOOFRotationManipulator.cpp
GOOFCommon/src/GOOFSceneManagerWrapper.cpp
GOOFCommon/src/GOOFSelectorDataFile.cpp
GOOFCommon/src/GOOFTranslationManipulator.cpp
GOOFCommon/src/GOOFWindow.cpp
GOOFCommon/src/GOOFWindowManager.cpp
GOOFCommon/src/GOOFXMLDataElement.cpp
GOOFCommon/src/GOOFXMLDataFile.cpp
GOOFCommon/src/tinystr.cpp
GOOFCommon/src/tinyxml.cpp
GOOFCommon/src/tinyxmlerror.cpp
GOOFCommon/src/tinyxmlparser.cpp
""")

# list of libraries needed for linking
libs_list=Split("""
GOOFAppFramework
GOOFCore
GOOFCommon

paginglandscape2
noise
OgreMain
OgrePlatform
Opcode
OIS
CEGUIOgreRenderer
CEGUIBase
boost_filesystem
""")

env.Library('GOOFAppFramework', goof_appframework_list)
env.Library('GOOFCore', goof_core_list)
env.Library('GOOFCommon', goof_common_list)

env.Program('gooftest', ['main-test.cpp', 'app-test.cpp'], LIBS=libs_list, LIBPATH='.')


Best regards,

hmoraldo

24-11-2006 17:59:04

I got the first program working in Linux (only using core, common, and appframework). I had to temporarily disable the interface manager as it was giving me some strange segfaults I still have to analyze. I'm still not sure if it's a problem with the code working in linux, or a problem in my installation as a few ogre samples are segfaulting here as well. But I guess it's a first step.

Best regards,

hmoraldo

24-11-2006 21:03:11

Well, I already solved that. Not the problem with the ogre samples, but the one with the goof interface.

I don't want to fill this thread with boring messages about the linux compiling... I'll only post again when I have reasonably interesting news (or questions!) on this.

Regards,

hmoraldo

25-11-2006 14:32:22

Well, unless I get some great idea from somewhere, I'm stuck.

I got the entire GOOF compiled, and could link all GOOFEd, with the plugging-in of some features disabled (so letting me start the goofed with an empty window only). Now when I try to enable any of those, I get the strangest link errors, including "undefined reference to vtable" for obviously well defined classes with all virtual functions defined as well.

It's the classic horror story about "undefined reference to vtable", but this time the solution isn't the classic "check for some undefined virtual function" as I isolated the problem and it continues happening even with the simplest classes (even with classes I myself add, that have an only virtual function and that compile in any other C++ project).

I'd need help from some kind of unix guru to finish the 'port', as I solved a lot of strange problems in the way to here, but this one is the strangest I've ever seen in link time. It's a pity I guess as the scons compiler was going to be very nice and intuitive, and the effort I put here was considerable (my cvs diff | grep . -c gives me around 900 line changes, and it wasn't over).

For a future linux port, I suggest GOOF maintainers check for a bunch of simple problems that arise too much times in code compilation in Linux:

- one I didn't correct at all (otherwise the diff would grow a lot): all code files lack the necessary blank file at end, as it's not there gcc prints hundreds of warnings

- gcc doesn't like that Ogre::uint, Ogre::ushort have been redefined out of Ogre namespace (as uint and ushort)... even if they are the same typedefs in both places, for gcc that is an ambiguity

- gcc doesn't like how the goof code calls functions passing parameters by reference, supplied by the return value of other functions, just like:

Well, maybe if at monday I get inspired I'll continue working on this, otherwise I'd wait for some free week in the future to get back to this problem, to see how to solve this.

If anyone is interested in trying to port the GOOF to linux, the following SConstruct file could be useful (only if you plan to use scons, or at least to see what you'll have to install previous to code compilation):

listinc=[
# just for this test
'.',

# location of ogre includes
'/usr/local/include/OGRE',
# location of boost includes
'/usr/include',
# location of cegui includes
'/usr/local/include/CEGUI',
# location of ois includes
'/usr/local/include/OIS',
# location of noise includes
'noise/include',

# location of both paging landscape includes
# (you'll need to install paginglandscape so that directories coincide)
'paginglandscape/PlugIns/PagingLandScape2/include',
'paginglandscape/Tools/MapSplitter/include',

# location of opcode includes
'opcode',

# location of all the goof includes
'GOOFAppFramework/include',
'GOOFCommon/include',
'GOOFCore/include',
'GOOFEd/include',
'GOOFEdPlugins/include',
'GOOFEdPlugins/GOOFGameObjectEditorPlugin/include',
'GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/include',
'GOOFEdSystem/include',
'GOOFExtension/include',
'GOOFGameSystems/include',
'GOOFGameSystems/GOOFOpcodeCollisionGameSystem/include',
'GOOFGameSystems/GOOFImpostorGameSystem/include',
'GOOFGameSystems/GOOFResourceBackgroundGroupGameSystem/include',
'GOOFGameSystems/GOOFEnvironmentGameSystem/include'
]
env=Environment(CPPPATH=listinc, LIBPATH='.')


# check for required include files and libraries
conf = Configure(env)
if not conf.CheckCXXHeader('Ogre.h'):
print 'Ogre must be installed!'
Exit(1)
if not conf.CheckLib('OgreMain'):
print 'OgreMain library must be in path'
Exit(1)
if not conf.CheckLib('OgrePlatform'):
print 'OgrePlatform library must be in path'
Exit(1)
if not conf.CheckCXXHeader('CEGUIBase.h'):
print 'CEGUI must be installed!'
Exit(1)
if not conf.CheckLib('CEGUIBase'):
print 'CEGUIBase library must be in path'
Exit(1)
if not conf.CheckLib('CEGUIOgreRenderer'):
print 'CEGUIOgreRenderer library must be in path'
Exit(1)
if not conf.CheckCXXHeader('OISPrereqs.h'):
print 'OIS must be installed!'
Exit(1)
if not conf.CheckLib('OIS'):
print 'OIS library must be in path'
Exit(1)
if not conf.CheckCXXHeader('OgrePagingLandScapeOptions.h'):
print 'Paging Landscape files should be in paginglandscape directory!'
Exit(1)
if not conf.CheckCXXHeader('Opcode.h'):
print 'Opcode should be in opcode directory! (and remember to modify the opcode files as asked in the wiki)'
Exit(1)
if not conf.CheckLib('Opcode'):
print 'Opcode library must be in path'
Exit(1)
if not conf.CheckCXXHeader('boost/version.hpp'):
print 'Boost must be installed!'
Exit(1)
if not conf.CheckCXXHeader('boost/filesystem/fstream.hpp'):
print 'Boost/filesystem must be installed!'
Exit(1)
if not conf.CheckLib('boost_filesystem'):
print 'boost_filesystem library must be in path'
Exit(1)
if not conf.CheckCXXHeader('noise/noise.h'):
print 'Libnoise files should be in noise directory! (and also move noise/include/* files to noise/include/noise/*)'
Exit(1)
if not conf.CheckLib('noise'):
print 'noise library must be in path'
Exit(1)
if not conf.CheckLib('paginglandscape2'):
print 'paginglandscape2 library must be in path'
Exit(1)


# list of files needed for compiling the GOOF App Framework
goof_appframework_list=Split("""
GOOFAppFramework/src/GOOFApplication.cpp
GOOFAppFramework/src/GOOFInterfaceManager.cpp
GOOFAppFramework/src/GOOFInterfaceScreen.cpp
""")

# list of files needed for compiling the GOOF Core
goof_core_list=Split("""
GOOFCore/src/GOOFCoreGameObjectManager.cpp
GOOFCore/src/GOOFCoreGameObject.cpp
GOOFCore/src/GOOFCorePartition.cpp
GOOFCore/src/GOOFCorePartitionManager.cpp
GOOFCore/src/GOOFFullSceneOperation.cpp
""")

# list of files needed for compiling the GOOF Common
goof_common_list=Split("""
GOOFCommon/src/GOOFAxisManipulator.cpp
GOOFCommon/src/GOOFCollisionGameSystem.cpp
GOOFCommon/src/GOOFDataFileResource.cpp
GOOFCommon/src/GOOFDataFileResourceManager.cpp
GOOFCommon/src/GOOFDragManipulator.cpp
GOOFCommon/src/GOOFFreeCamInputController.cpp
GOOFCommon/src/GOOFGameObjectFactoryManager.cpp
GOOFCommon/src/GOOFGameSystemManager.cpp
GOOFCommon/src/GOOFGenericUtils.cpp
GOOFCommon/src/GOOFInputListener.cpp
GOOFCommon/src/GOOFLine3D.cpp
GOOFCommon/src/GOOFMessageWindow.cpp
GOOFCommon/src/GOOFOperationManager.cpp
GOOFCommon/src/GOOFOverheadCamInputController.cpp
GOOFCommon/src/GOOFProperty.cpp
GOOFCommon/src/GOOFPropertyContainer.cpp
GOOFCommon/src/GOOFRotationManipulator.cpp
GOOFCommon/src/GOOFSceneManagerWrapper.cpp
GOOFCommon/src/GOOFSelectorDataFile.cpp
GOOFCommon/src/GOOFTranslationManipulator.cpp
GOOFCommon/src/GOOFWindow.cpp
GOOFCommon/src/GOOFWindowManager.cpp
GOOFCommon/src/GOOFXMLDataElement.cpp
GOOFCommon/src/GOOFXMLDataFile.cpp
""")
# these, commented out (HHM TODO)
"""
GOOFCommon/src/tinystr.cpp
GOOFCommon/src/tinyxml.cpp
GOOFCommon/src/tinyxmlerror.cpp
GOOFCommon/src/tinyxmlparser.cpp
"""

# list of files needed for compiling the GOOF Extension
goof_extension_list=Split("""
GOOFExtension/src/GOOFCompoundGameObject.cpp
GOOFExtension/src/GOOFExtensionGameObjectFactory.cpp
GOOFExtension/src/GOOFGridPartition.cpp
GOOFExtension/src/GOOFGridPartitionManager.cpp
GOOFExtension/src/GOOFLightGameObject.cpp
GOOFExtension/src/GOOFMeshGameObject.cpp
GOOFExtension/src/GOOFParticleSystemGameObject.cpp
GOOFExtension/src/GOOFPlaceHolderGameObject.cpp
GOOFExtension/src/GOOFSinglePartitionManager.cpp
""")

# list of files needed for compiling the GOOF Impostor Game System
goof_impostorgamesystem_list=Split("""
GOOFGameSystems/GOOFImpostorGameSystem/src/GOOFImpostorGameSystem.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/GOOFImpostorGameSystemFactory.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/GOOFImpostorHandler.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/EntityMaterialInstance.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/MaterialInstance.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/QuadtreeTextureSpace.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/QuadtreeTextureSpacePool.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/SubEntityMaterialInstance.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/UniqueImpostorHandler.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/UniqueImpostorManager.cpp
GOOFGameSystems/GOOFImpostorGameSystem/src/UniqueImpostorSet.cpp
""")

# list of files needed for compiling the GOOF Environment Game System
goof_environmentgamesystem_list=Split("""
GOOFGameSystems/GOOFEnvironmentGameSystem/src/GOOFEnvironmentGameSystem.cpp
GOOFGameSystems/GOOFEnvironmentGameSystem/src/GOOFEnvironmentGameSystemFactory.cpp
""")

# list of files needed for compiling the GOOF Resource Background Group Game System
goof_resourcebackgroundgroupgamesystem_list=Split("""
GOOFGameSystems/GOOFResourceBackgroundGroupGameSystem/src/GOOFResourceBackgroundGroup.cpp
GOOFGameSystems/GOOFResourceBackgroundGroupGameSystem/src/GOOFResourceBackgroundGroupGameSystem.cpp
GOOFGameSystems/GOOFResourceBackgroundGroupGameSystem/src/GOOFResourceBackgroundGroupUtilities.cpp
""")

# list of files needed for compiling the GOOF Opcode Collision Game System
goof_opcodecollisiongamesystem_list=Split("""
GOOFGameSystems/GOOFOpcodeCollisionGameSystem/src/GOOFOpcodeCollisionGameSystem.cpp
GOOFGameSystems/GOOFOpcodeCollisionGameSystem/src/GOOFOpcodeCollisionGameSystemFactory.cpp
GOOFGameSystems/GOOFOpcodeCollisionGameSystem/src/GOOFOpcodeCollisionShape.cpp
""")

# list of files needed for compiling the GOOF Opcode Collision Game System
goof_edsystem_list=Split("""
GOOFEdSystem/src/GOOFEditorPlugin.cpp
GOOFEdSystem/src/GOOFEditorPropertiesWindow.cpp
GOOFEdSystem/src/GOOFEditorSystem.cpp
GOOFEdSystem/src/GOOFEditorTool.cpp
""")

# list of files needed for compiling the GOOF Game Object Editor Plugin
goof_gameobjecteditorplugin_list=Split("""
GOOFEdPlugins/GOOFGameObjectEditorPlugin/src/GOOFGameObjectEditorPlugin.cpp
GOOFEdPlugins/GOOFGameObjectEditorPlugin/src/GOOFGameObjectEditorTool.cpp
GOOFEdPlugins/GOOFGameObjectEditorPlugin/src/GOOFGameObjectPropertyContainerProxy.cpp
GOOFEdPlugins/GOOFGameObjectEditorPlugin/src/GOOFSelectOperation.cpp
""")

# list of files needed for compiling the GOOF Paging Landscape Editor Plugin
goof_paginglandscapeeditorplugin_list=Split("""
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFLibnoiseGenerator.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFPagingLandscapeEditorPlugin.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFPagingLandscapeEditorTool.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFPagingLandscapeNewLandscapeFinishWindow.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFPagingLandscapeNewLandscapeImportWindow.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFPagingLandscapeNewLandscapeLibnoiseWindow.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/GOOFPagingLandscapeNewLandscapeWindow.cpp
GOOFEdPlugins/GOOFPagingLandscapeEditorPlugin/src/noiseutils.cpp
paginglandscape/Tools/MapSplitter/src/filetutils.cpp
paginglandscape/Tools/MapSplitter/src/MapBlender.cpp
paginglandscape/Tools/MapSplitter/src/MapBlurrer.cpp
paginglandscape/Tools/MapSplitter/src/MapEqualizer.cpp
paginglandscape/Tools/MapSplitter/src/MapHorizon.cpp
paginglandscape/Tools/MapSplitter/src/MapHorizon2.cpp
paginglandscape/Tools/MapSplitter/src/MapHorizon3.cpp
paginglandscape/Tools/MapSplitter/src/MapInfinitizer.cpp
paginglandscape/Tools/MapSplitter/src/MapLighter.cpp
paginglandscape/Tools/MapSplitter/src/MapMergeModulater.cpp
paginglandscape/Tools/MapSplitter/src/MapNormaler.cpp
paginglandscape/Tools/MapSplitter/src/MapSplatter.cpp
paginglandscape/Tools/MapSplitter/src/MapSplitter.cpp
paginglandscape/Tools/MapSplitter/src/MapTool.cpp
paginglandscape/Tools/MapSplitter/src/MapUtil.cpp
paginglandscape/Tools/MapSplitter/src/MapVis.cpp
""")

# list of files needed for compiling the GOOF Game Object Editor Plugin
goof_ed_list=Split("""
GOOFEd/src/GOOFEditorApplication.cpp
GOOFEd/src/GOOFEditorScreen.cpp
GOOFEd/src/main.cpp
""")



# list of libraries needed for linking
libs_list=Split("""
GOOFAppFramework
GOOFCore
GOOFCommon
GOOFImpostorGameSystem
GOOFEnvironmentGameSystem
GOOFExtension
GOOFResourceBackgroundGroupGameSystem
GOOFOpcodeCollisionGameSystem
GOOFEdSystem
GOOFGameObjectEditorPlugin
GOOFPagingLandscapeEditorPlugin

paginglandscape2
noise
OgreMain
OgrePlatform
Opcode
OIS
CEGUIOgreRenderer
CEGUIBase
boost_filesystem
""")

env.Library('GOOFAppFramework', goof_appframework_list)
env.Library('GOOFCore', goof_core_list)
env.Library('GOOFCommon', goof_common_list)
env.Library('GOOFExtension', goof_extension_list)
env.Library('GOOFImpostorGameSystem', goof_impostorgamesystem_list)
env.Library('GOOFEnvironmentGameSystem', goof_environmentgamesystem_list)
env.Library('GOOFResourceBackgroundGroupGameSystem', goof_resourcebackgroundgroupgamesystem_list)
env.Library('GOOFOpcodeCollisionGameSystem', goof_opcodecollisiongamesystem_list)
env.Library('GOOFEdSystem', goof_edsystem_list)
env.Library('GOOFGameObjectEditorPlugin', goof_gameobjecteditorplugin_list)
env.Library('GOOFPagingLandscapeEditorPlugin', goof_paginglandscapeeditorplugin_list)

#env.Program('gooftest', ['main-test.cpp', 'app-test.cpp', 'screen-test.cpp'], LIBS=libs_list, LIBPATH='.')
env.Program('goofed', goof_ed_list, LIBS=libs_list, LIBPATH='.')


And sorry for the huge posts, I was trying to help :(

Best regards,

Falagard

25-11-2006 19:16:28

Thank you very much for your attempts to port GOOF.

I personally have never worked on Linux, but do intend to get GOOF working on Linux because I'd like to write multiplayer networking code with support for standalone servers running on cheap Linux boxes.

1. The blank file at the end - is this some sort of "end of file" character? Any idea how I'd fix this?

2. Any idea where they were redefined out of the Ogre namespace? Was this done in a dependant library like Opcode or something?

3. GOOF code calling functions passing parameters by reference, supplied by the return value of other functions.... you ended your sentence with just like: ... but without continuing. I think I know what you mean, but if you provided an example I'll attempt to avoid it in the future.

Thank you very much for your attempts to help!

Clay

DamnWidget

25-11-2006 19:55:48

Greetings, I got the same problem than sexinzer0, when I try to run the GOOFed.exe I get a runtime error, I already debugged the application.

When the execution come this point at Root::startRendering(void)


while( !mQueuedEnd )
{
//Allow platform to pump/create/etc messages/events once per frame
mPlatformManager->messagePump(mAutoWindow);

if (!renderOneFrame())
break;
}


do one cicle, and then jump to :

void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
/* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
(_Reserved);
_debugger_hook_dummy = 0;
}


at dbghook.c

The fact is the only strange thing I saw while debuging is the pointer casted to mVersion becomes NULL.

Any clue?

Falagard

25-11-2006 22:56:41

Sorry, that's not enough information.

What version of Ogre are you using? GOOF hasn't been tested with the latest version of Ogre, nor the latest version of PLM2.

renderOneFrame is probably causing an exception inside it. Try turning on break on exceptions in Visual Studio. Be sure to compile in debug.

Let me know if you hit a particular error when you do that.

hmoraldo

27-11-2006 22:32:06

1. The blank file at the end - is this some sort of "end of file" character? Any idea how I'd fix this?

Sorry, I simply meant "a blank line". Just add a blank line at the end of all h and cpp files.

2. Any idea where they were redefined out of the Ogre namespace? Was this done in a dependant library like Opcode or something?

Hmmm... it seems that's happening in /usr/include/sys/types.h

I guess you solve it simply by using Ogre::uint and Ogre::ushort everywhere

3. GOOF code calling functions passing parameters by reference, supplied by the return value of other functions.... you ended your sentence with just like: ... but without continuing. I think I know what you mean, but if you provided an example I'll attempt to avoid it in the future.

An example:

success = load(DataElementPtr(new XMLDataElement(NULL)));

A terrible way to make it work is:

GOOF::DataElementPtr delptr_tmp=dataFile->getRootElement();
GOOF::DataElementPtr& delptr=delptr_tmp;
success = load(delptr);


Ie, this wouldn't work either:

GOOF::DataElementPtr& delptr=dataFile->getRootElement();
success = load(delptr);


I'm not really sure what would the real right way to solve this, I'm sure my three-line replacement isn't nice, but at this stage I'm just trying to get it to work no-matter-what in my linux box, then I'll see how to make the code nicer and how to do a nice setup process (though the current scons process is very nice at the least!)

And a 4. There are some includes calling for filenames that are in the wrong case... they happen with CEGUICombobox.h, Opcode.h, QuadtreeTextureSpacePool, QuadtreeTextureSpace, OgrePagingLandScapeRaySceneQuery.h, and tinyxml.h.

And at last... I said about 900 line changes, that was a mistake... its "cvs diff | grep . -c" that returns 900, it would mean about half that number of line changes.

I'll probably keep working on this, I have not much time but I'm very interested in making this work in Linux.

Thank you for your time!

Best regards,

hmoraldo

28-11-2006 13:52:42

Well, I keep getting a lot of undefined references when linking; and when I get it to link by disabling some plugins, it doesn't go a lot further: I get segfaults sooner or later.

I'll probably investigate later, but I'm getting sure that it's a problem with my set of libraries here. I probably have an incompatible set of libraries, so even if I compiled this it wouldn't work well; I guess I'll wait for a next release, so I'm sure I have the right libraries to be used for compiling the Goof.

I'm also going to start using Eihort now (used Dagon until now)... a small question: when do you plan to go to Eihort with Goof?

Best regards,

giulian2003

29-03-2007 16:08:58

Anything new happening here? How are the things proceeding?

Falagard

29-03-2007 20:55:51

I've ported GOOF to Eihort but don't have PLM2 working and probably won't until PLM3 is released.

I'm changed the way GOOF is set up so that I can hand out binary dependencies and you can compile GOOF within minutes of downloading it. I also have made major changes to the various projects, made the system load everything dynamically via plugins, and renamed the engine to something secret that I won't announce until I release the next version ;-)

I'm currently working on a binary file format and changes to how everything loads and saves. The basic idea is that everything saves and loads to/from binary streams (istream and ostream), but XML is treated as an intermediary file format. So programmers and designers can open up the XML, edit it, etc. and it'll be converted to binary when the engine starts and then all classes (GameObjects, GameSystems, Partitions, etc) always just load from binary. Also, when anything saves from within the engine, it saves to binary and gets converted back to XML. Obviously when the game is released you'll only release the binary data files and the XML conversion won't happen.

So yeah, things are coming along.

maxxoros

31-03-2007 04:44:48

It s great when knowing that GOOF is develop so fastly :)..
Keep it up. I hope to see the official release soon
===
BTW, have you change the whole GUI to wxWidget instead of the old fashion and low-loading CeGUI :roll:

Falagard

31-03-2007 05:15:41

... GOOF is develop so fastly....

I think most people, including me, would disagree with this :-) GOOF is going very slowly. But thanks for the encouragement.

Yes, the editor GUI is now completely done in wxWidgets and I think it looks pretty nice.

andy

08-07-2007 03:31:59

Are you making the latest (current/development) version available?

ie It looks like the CVS (in OgreAddons) hasn't been updated in a while :)

Cheers

Andy

dudeabot

16-07-2007 21:19:23

this reminds of torque game engine, but with more possibilities :D

i hope the development is going well

im downloading some dependencies to see if i can run the version avaliable on CVS

bibiteinfo

17-07-2007 03:54:49

GOOF can be port to Eihort without much trouble ... there is issues with PLSM2 raycast and a lot with CEGUI, but if you stay with CEGUI 0.4, it shouldn't take long to do the port.

mybios

17-07-2007 07:56:47

to Falagard: can you release a new version of GOOF?
I here that you have make a new editor using wxWeight. I want to use that.
Thank you . I eager anticipation....

Falagard

17-07-2007 15:22:33

I've promised someone that it will be released mid August. It will not have terrain editing features though, so don't be looking for that :-) Sorry. It's more of a game engine and object placement editor.

mybios

18-07-2007 02:11:20

I've promised someone that it will be released mid August. It will not have terrain editing features though, so don't be looking for that :-) Sorry. It's more of a game engine and object placement editor.

Thank you very much. I think I can add terrain edting features by myself. Very espect to ....

jacmoe

18-07-2007 22:07:18

I've promised someone that it will be released mid August. It will not have terrain editing features though, so don't be looking for that :-) Sorry. It's more of a game engine and object placement editor.
Wow, does that mean that GOOF is actually alive? I thought it was left as-is - quite looking forward to checking out the new version, Falagard! :)

Falagard

19-07-2007 18:31:37


Wow, does that mean that GOOF is actually alive? I thought it was left as-is - quite looking forward to checking out the new version, Falagard! Smile


It's alive. It hasn't progressed as much as you might hope since the last release, but it's alive.

jacmoe

19-07-2007 20:04:00

I didn't expect any radical release, as I know you have enough on your plate (as always).
I am just very glad to learn that you are still GOOFing around.
Very important project IMO. :)

Paulov

24-07-2007 20:53:34

Hey

very nice!!

Dont forget to release a binary version for those artist like me that want to put their hands on it.

(( .osm support would rock !!))

congrats on releasing your first GOOF demo!!!

I´ll be in Croatia those days, so , congrats in advance :P

bye bye

cloud9

11-08-2007 10:02:14

Maybe you've caught this in the new GOOF, but

CoreGameObject::setOrientation

should have something like this in it.


Vector3 src = node->_getDerivedOrientation() * Vector3::UNIT_Z;
Vector3 dest = orientation * Vector3::UNIT_Z;
Quaternion q = src.getRotationTo(dest);

node->rotate(q, Node::TS_WORLD);

// z axis of node is the same as q's
// x and y arn't right yet

src = node->_getDerivedOrientation() * Vector3::UNIT_X;
dest = orientation * Vector3::UNIT_X;
q = src.getRotationTo(dest);

node->rotate(q, Node::TS_WORLD);


Its a small thing.

raptoravis

16-08-2007 15:54:47

looking forward to the latest version!

Falagard

17-08-2007 02:39:25

Thanks for showing me that bug.

Don't hold your breath on the latest version of GOOF. It's definitely not coming out this week.

Rendar

17-08-2007 08:13:37

Thanks for showing me that bug.

Don't hold your breath on the latest version of GOOF. It's definitely not coming out this week.


Just curious if you're still on target for an August release as you mentioned earlier?

Can't wait to check it out.

jingjie

27-08-2007 16:25:20

Thanks for showing me that bug.

Don't hold your breath on the latest version of GOOF. It's definitely not coming out this week.


Just curious if you're still on target for an August release as you mentioned earlier?

Can't wait to check it out.

Master Falagard:
I would upgrade GOOF on OGRE v1.4.4 :cry: then suffer many questions not to solve by myself.
So that I check out the lastest GOOF from OGRE ADDONS , but it's still the CEGUI version ,not wxWidget. About August release, how can I get it ? :P

bibiteinfo

27-08-2007 17:20:56

Download the source from my project, it's GOOF set up on V.1.4.2, but should work on 1.4.4

http://sourceforge.net/projects/argorha and download the src.

And if you read what Falagard just told, don't hold your breath, it's not going to be in august.

raptoravis

28-08-2007 16:26:32

to bibiteinfo,

I used your source and it has linking errors to RenderSystem_GL and RenderSystem_Direct3D9. the strange thing is I can find RenderTarget::update in OgreRenderTarget.cpp!

------ Build started: Project: RenderSystem_GL, Configuration: Debug Win32 ------
Linking...
Creating library ..\..\..\lib/RenderSystem_GL_d.lib and object ..\..\..\lib/RenderSystem_GL_d.exp
OgreWin32Window.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::update(bool)" (?update@RenderTarget@Ogre@@UAEX_N@Z)
OgreGLFBOMultiRenderTarget.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::update(bool)" (?update@RenderTarget@Ogre@@UAEX_N@Z)
OgreGLFBORenderTexture.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::update(bool)" (?update@RenderTarget@Ogre@@UAEX_N@Z)
OgreGLPBRenderTexture.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::update(bool)" (?update@RenderTarget@Ogre@@UAEX_N@Z)
OgreGLRenderTexture.obj : error LNK2019: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::update(bool)" (?update@RenderTarget@Ogre@@UAEX_N@Z) referenced in function "public: virtual class Ogre::MultiRenderTarget * __thiscall Ogre::GLRTTManager::createMultiRenderTarget(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?createMultiRenderTarget@GLRTTManager@Ogre@@UAEPAVMultiRenderTarget@2@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
OgreGLFBOMultiRenderTarget.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::swapBuffers(bool)" (?swapBuffers@RenderTarget@Ogre@@UAEX_N@Z)
OgreGLFBORenderTexture.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::swapBuffers(bool)" (?swapBuffers@RenderTarget@Ogre@@UAEX_N@Z)

raptoravis

28-08-2007 16:33:22

ok, i double checkedc the source code.

in OgreRenderTaget.cpp
it is defined this way,
void RenderTarget::update(void)

but, the error:
OgreWin32Window.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Ogre::RenderTarget::update(bool)" (?update@RenderTarget@Ogre@@UAEX_N@Z)

shows it is used with a param bool.

there is still a strange thing: i can't find where it is called in OgreWin32Window.cpp

bibiteinfo

28-08-2007 16:47:06

Something I didin't mentionned and might cause the error is that I compiled Ogre with the flag OGRE_THREAD_SUPPORT set to 1 in the file OgreConfig.h.

To be sure, are you using the Ogre V.1.4.2? Not the HEAD

And if you had previously built Ogre, did you made a clean rebuild?

raptoravis

29-08-2007 02:31:01

originally, i used head and the orgenew was ok. then, I used 1.4.2 according to your info. anyway, I will try to enabled that macro and do a rebuild. thanks

raptoravis

29-08-2007 16:44:18

can't believe it, i finally built Goof successfully for the 1st time ever using 1.4.2 after a rebuild.

with several modifications:

1. add plugin Octree into sln

2. change PagingLandScapeSceneManager2 lib path

3. change couple of cfg files

thanks, esp. to bibiteinfo!

bibiteinfo

29-08-2007 17:25:51

It's true for the 1, I always need to rebuild Ogre from the Ogre.sln, I'm just too lazy to add Octree in GOOF :P, I think I'm gonna do it for my next src release.

What's the problem with Paginglandscape lib path?

At first, did you took cfg files from GOOFMedia or just the one that were already there?

And yeah compiling GOOF is always a pain the first time and when I skrew my folder, my hands shake; After 10 times, you start to get the idea :P

raptoravis

30-08-2007 02:39:00

Paginglandscape lib path originally is something like: ..\..\..\OgreMain\lib\$(ConfigurationName), it should be ..\..\..\lib

anyway, i think this is because i am using the source release instead of SDK release.

raptoravis

30-08-2007 02:40:03

and, btw, i use vs2005

pitmodano12

06-09-2007 10:39:34

UPDATE GOOF Editor is now available in ogreaddons. . On the same topic, Don't forget to include static/moving, occluder/non-occluder in object properties

Paulov

06-09-2007 10:47:38

mmm

so, is GOOF 1.0 launched?¿

I´ve been giving a look to cvs directory and found no.exe

so, if the 1.0 version is ready coud someone provide me with a compiled version?

I would upload it for free in my FTP and serve it in direct download.

Bye.

Falagard

06-09-2007 17:16:04

Um what? :-) GOOF has been in ogreaddons for more than a year. That's an old version. No GOOF isn't ready.

Rendar

07-09-2007 06:53:12

Hey Falagard,

Is the GOOF editor still kind of a plugin framework?

The more I've been thinking about editors for a system like Ogre, the more I think that a plugin system is definitely the way to go. Since so many types of applications can be made with Ogre why make a set editor that only a few projects could end up using?

Instead, make a plugin framework that people can develop specific plugins for... say, one plugin for cloud systems, another for water effects, another for terrain, another for particle effects, etc. Basically a "build your own editor".

Falagard

07-09-2007 14:48:31

Hey Falagard,

Is the GOOF editor still kind of a plugin framework?

The more I've been thinking about editors for a system like Ogre, the more I think that a plugin system is definitely the way to go. Since so many types of applications can be made with Ogre why make a set editor that only a few projects could end up using?

Instead, make a plugin framework that people can develop specific plugins for... say, one plugin for cloud systems, another for water effects, another for terrain, another for particle effects, etc. Basically a "build your own editor".


Yup, entirely plugin based.

Rendar

08-09-2007 02:53:00

Hey Falagard,

Is the GOOF editor still kind of a plugin framework?

The more I've been thinking about editors for a system like Ogre, the more I think that a plugin system is definitely the way to go. Since so many types of applications can be made with Ogre why make a set editor that only a few projects could end up using?

Instead, make a plugin framework that people can develop specific plugins for... say, one plugin for cloud systems, another for water effects, another for terrain, another for particle effects, etc. Basically a "build your own editor".


Yup, entirely plugin based.


Hehe I can't wait to check it out when the next release is done.

On a side note, is any of the current documentation/code for the plugin framework (as far as what is needed to create the interaction code on the plugin's side) basically the same for the version you're working on now?

Falagard

08-09-2007 14:33:51

You mean is it the same compared to what's currently in CVS?

No.

There's a Plugin base class, PluginFactory and a PluginFactoryManager singleton.

Every plugin must inherit from the Plugin base class (or a class that ultimately derives from Plugin). PluginFactory is associated with a PluginType string and has a function called createPlugin(). You register plugin factories with the PluginFactoryManager.

So for example, let's say the editor has a class called EditorTool which inherits from Plugin.

You create a ParticleEditorTool class which derives from EditorTool and has particle editing functionality. You create a ParticleEditorToolFactory which derives from PluginFactory and override the createPlugin() function to return instances of ParticleEditorTool. You compile that into a DLL and when the DLL is loaded you register the ParticleEditorToolFactory with the PluginFactoryManager under the name "ParticleEditorTool".

Then there's a config file for the Editor which lists the tool names. The editor automatically creates the tools using the names by calling

EditorTool* tool = static_cast<EditorTool*>(PluginFactoryManager::getSingleton().createPlugin("ParticleEditorTool"));

katzenjoghurt

16-09-2007 21:08:29

Hi!

Hm.... spent 2 days now trying to compile GOOF. The wiki of the paging scene manager said that the only working editor for it I'd find in the GOOF project.
Okay... ended up getting compatibility issues between OGRE <-CEGUI-> GOOF ... and gave finally up.

Then I found bibiteinfo's expanded GOOF version.
Yet ... painting is broken (okay... read this in the wiki later) ... and much worse... I can't save / load files. (Or am I doing something wrong?)
Typing save as... "mymap" results in a flickering but i won't find it on my harddisc later ... and I won't be able to load it. Pushing the "save" button and entering a name... the editor crashes.

Is GOOFEd usable at all? Okay... it's alpha and everything ... but as far as I understand, everyone using the paging manager is also using GoofEd.
If I understood that wrong ... how do you generate your maps (Hightmaps + Map splitter ?) and more importantly... place your objects?

bibiteinfo

17-09-2007 00:02:04

ok the compatibility problem that you've got trying to compile Ogre, CEGUI and GOOF is because you choose ogre V1.4.x

My version is by no mean usable by an artist, it's a demo to show the pathfinding, nothing more.

The reason it's that way is that CEGUI has change version since Ogre V.1.2 and it broke a lot of code in GOOF. My version just patch those problems so it can compile against Ogre V1.4, but at the same time, when it run back, a lot of stuff was not going well like Save and load, painting and so on that worked with previous CEGUI version and Ogre V1.2.

If there's a real need for a good working version I could spend time on fixing the save and load and painting.

In the same time, a new GOOF version will arrived someday and I don't want to spend a month of debug on something that will be changed the month after. This is the main reason for me not patching all those problems at start, so I just have done what I needed for my pathfinding. I give the code away so it can be a basis for people to compile against 1.4 and can patch what they need. It has been one of those nightmare upgrading CEGUI.

Tell me your thought.

katzenjoghurt

17-09-2007 01:17:19

Hey bibite! :)

Thing is... that my artists want to create a pretty vast subwater landscape. So - for me - the paging scene manager seems to be just great for the purpose. But I got no tool to give them to create the content. :)

Didn't see that there are some tradeoffs with your pathfinding version of GOOF.

For me, I don't see the point of compiling Goof against Ogre 1.4.x.
And ... I'm also sure, Falagard will suddenly surprise us with his new Goof version and all the work would have been in vain.

But if you or someone else got a running (original) Goof version for me I'd be just happy.

If not ... I'll install VC 7.1 and try once more to compile it. With VC8 I didn't have much luck. :)

Maybe there's a completely different solution as well... I'll have one more look in the wiki and the add-on folder.

bibiteinfo

17-09-2007 01:42:41

Well what are your problems with VC8, I didn't experience any problem related to VC8. There is no other solution that I know for map modification than original GOOF and map editor which is broken.

katzenjoghurt

17-09-2007 10:41:18

I got some linking errors with FreeImage.lib I couldn't resolve... thought they came from the VS 2003 -> 2005 conversion after reading the last posting here:

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

bibiteinfo

17-09-2007 14:37:54

You did not get the good dependencies, the good package is :

http://sourceforge.net/project/downloading.php?groupname=ogre&filename=OgreDependencies_VC8_1.2.0p2.zip&use_mirror=umn

And if necessary you can download Ogre V1.2.5 there :

http://downloads.sourceforge.net/ogre/ogre-win32-v1-2-5.zip?download

katzenjoghurt

17-09-2007 15:52:12

Hm... . I took 1.2.1 Ogre and it's dependencies as written in the wiki ... just installed VS 7.1 .... but okay .... I'll try with the ones you linked. Thx! :D

(Wonder what will happen when I load a 1.4.0 oder 1.30 mesh serialized .mesh in it...)

bibiteinfo

17-09-2007 17:28:56


(Wonder what will happen when I load a 1.4.0 oder 1.30 mesh serialized .mesh in it...)


ouch :o

katzenjoghurt

17-09-2007 18:09:44

ouch will happen?
Great! :)


Works much smoother with your dependencies ... strange ... why didn't do the 1.2.1 ones?

Yet... damn... PLSM2 won't build against Ogre 1.2.5 any more...

error C2061: Syntaxfehler: Bezeichner 'VisibleObjectsBoundsInfo'

...which means: 'VisibleObjectsBoundsInfo' has not been declared.

Strangely the forum search didn't spit out anything ... yet google did.

Indeed it's missing in 1.2.5's OgreSceneManager.h :(

ervilha

21-09-2007 18:58:38

ouch will happen?
Great! :)


Works much smoother with your dependencies ... strange ... why didn't do the 1.2.1 ones?

Yet... damn... PLSM2 won't build against Ogre 1.2.5 any more...

error C2061: Syntaxfehler: Bezeichner 'VisibleObjectsBoundsInfo'

...which means: 'VisibleObjectsBoundsInfo' has not been declared.

Strangely the forum search didn't spit out anything ... yet google did.

Indeed it's missing in 1.2.5's OgreSceneManager.h :(


I had the same problem 5 minutes ago, but it's working fine now :P

Just download this FILE, extract it, and replace the PagingLandScape2 folder in ogrenew/plugins/ by the same folder that is in the zip file!

Further problems??? i don't know, i'm testing this as i speak!

katzenjoghurt

21-09-2007 19:01:34

to be honest ... I gave up ... didn't know where to find the old version. So Tuan hosted it. :oops:
Took the one from the add-on folder.

ervilha

21-09-2007 19:28:09

i've took the add-on folder too, but that one is working wtih ogre 1.4.x, and ogre 1.2.1, dont define the structure "VisibleObjectsBoundsInfo" required to compile PLSM2(CVS head version).

So getting an older version without updating all addons folder was the solution.

Don't give up, just keep trying and exploring :P

katzenjoghurt

21-09-2007 23:52:03

thx, ervilha .... finally managed to build it.

Yet, it crashes here when trying to load a map after saving. :(

raptoravis

25-09-2007 02:30:21

eager for the latest release though!

leonardoaraujo.santos

25-09-2007 12:57:50

Hi guys .. One question...
If I manage to compile PLSM2, Goof, in Ogre 1.25 I still cant use Goof editor (At least edit and save some PLSM2 Map?.....)

Another question... there is another option to create an Map with PLSM2?

jony888

26-09-2007 19:37:18

Hi there,

I'm very keen on GOOF but the installation on ogre3d wiki only have GOOF installation with Ogre v1.2.1 which old dependencies I can't find anywhere. could anyone suggest me the latest installation instruction for GOOF? I heard someone mention he managed to get it working on ogre v1.4.2, I reckon that's good enough.

Thank you.

katzenjoghurt

26-09-2007 19:44:29

bibiteinfo has managed to get it to work with 1.4.2 ... but the GUI does rather fancy things and loading and saving is no longer possible.

He also posted the links to the 1.2.5. dependencies to build GOOF on Mon Sep 17, 2007 1:37 pm here in the thread.

Do yourself a favor and try them. I lost days trying to get it a work with 1.4.

As I said I still can't load a saved map though .... so I got away from GOOF again.

leonardoaraujo.santos

28-09-2007 03:49:51

Hi guys I've sucessfully compiled and tested Goof editor in Ogre 1.21 ... In this version I can Load and Save maps.....

Unfurtnently I can´t use with Ogre 1.4x.

I will just create and Edit my terrain with Goof Editor in Ogre 1.2.1 and copy the terrain folder to my project that uses Ogre 1.4.4 (I dont test this yet...).

leonardoaraujo.santos

28-09-2007 12:35:04

One questions guys after I save an map in GoffEditor it creates an Directory in C:\Ogrenew\Samples\Media\paginglandscape2\terrains\MyTerrain and a bunch of cfg files in C:\Ogrenew\Samples\Media\paginglandscape2\terrains\MyTerrain.cfg.

What I must do to run this map in the Demo_PagingLandScape2.exe Application?

Thanks and sorry for my english an this newbie question

jony888

28-09-2007 22:53:07

Could anyone pin point me to where I can find information about to build GOOF using Ogre 1.4?

bibiteinfo

28-09-2007 23:03:56

Could anyone pin point me to where I can find information about to build GOOF using Ogre 1.4?

Two ways as I said before :
1)
Getting my code which compile against Ogre V1.4 : http://www.sourceforge.net/projects/argorha compile it like it is described on this site : http://www.ogre3d.org/wiki/index.php/Game_Object_Oriented_Framework_Installation
And correct the remaining bugs to make it work properly, the compilation problems has been solved, not all the functionnalities.

2)
Take the GOOF code as it is right now on OgreAddons and make it compile along the same link as before. If you do so, one of my warning would be to take a previous version of CEGUI, almost all errors where coming from there. The Ogre errors where mostly the ray and PLSM2.

jony888

30-09-2007 01:46:20

I tried to follow the the GOOF instruction using Ogre 1.21 but i encounter lots of error:

OgreILUtil.cpp(32) : fatal error C1083: Cannot open include file: 'IL/il.h': No such file or directory

another:

OgrePagingLandScapeOcclusionElement.h(29) : error C2061: syntax error : identifier 'VisibleObjectsBoundsInfo'

And final question: which verion of CEGUI should we use?
It seems that we need DevIL libary, is that right?

Thank you guys.

bibiteinfo

30-09-2007 16:44:58

Read the page 29, all those questions has been answered.

Basicly, you don't have the right dependencies and not the good PLSM2

jony888

30-09-2007 19:03:02

Thank you bibiteinfo for your help but where can i find this page 29?

leonardoaraujo.santos

30-09-2007 19:21:44

Hi jonny888 I think bibiteinfo is reffering to the right bottom link that you choose the "topic pages" there you will see that has a lot of talk about Ogre 1.4.x Goof compiling

leonardoaraujo.santos

02-10-2007 18:52:27

Good news guys. I finally managed to compile Goof Editor (With Ogre 1.20 with 1.2x Dependencies), create a terrain and use it in the PLSM2 Demo application (With Ogre 1.4.5) with minimal changes to the CFG files.

Editor


PLSM2 Demo application


This is the Alples.cfg (Altered to my terrain created with Goof ed)

The only change I need to do in my created terrain (Alpes) was add:
# where to put camera on load. (Only change needed to run in Demo)
BaseCameraViewpoint.x=-396.0f
BaseCameraViewpoint.y=31000.0f
BaseCameraViewpoint.z=2640.0f

For some reason the terrain is over lighted (As soon I've discover how to fix this I will post on this topic)

Obs: I don't know why but Goof editor can't load and save maps with Ogre 1.4.x (Maybe is a problem with new CEGUI) I will try to recompile Goof editor wih Debug symbols and try to discover why it crashes in Ogre 1.4.x


AvgColorsExists=yes
CameraThreshold=1
Deformable=yes
FileSystem=LandScapeFileName
#FileSystem=terreno_plano
GroupName=PLSM2
Height=2
LandScapeExtension=raw
LandScapeFileName=Alpes
MaterialDistanceLod=256
MaxAdjacentPages=8
MaxNumRenderables=256
MaxNumTiles=256
MaxPixelError=6
MaxRenderLevel=5
NumMatHeightSplat=4
NumTextureFormatSupported=1
PageSize=129
ScaleX=257
ScaleY=1024
ScaleZ=257
#ScaleX=4000
#ScaleY=4000
#ScaleZ=4000

SplatFilename0=Terrain_Dirt1.jpg
SplatFilename1=Terrain_Rock1.jpg
SplatFilename2=Terrain_Grass1.jpg
SplatFilename3=Terrain_Cobble1.jpg
TextureFormat=PLSplattingShaderLit
#TextureFormatSupported0=PLSplattingShaderLit
TextureFormatSupported0=Base
#TextureModifiable=yes
TextureStretchFactor=2
TileSize=65
VertexCompression=yes
VertexLit=yes
VertexNormals=yes
VertexProgramMorph=yes
VisibleRenderables=256
Width=2

# where to put camera on load. (Only change needed to run in Demo)
BaseCameraViewpoint.x=-396.0f
BaseCameraViewpoint.y=31000.0f
BaseCameraViewpoint.z=2640.0f

bibiteinfo

03-10-2007 02:29:50

Seems like crashes from 1.4.x are coming from my pathfinding code :oops: , I'll try to fix it.

leonardoaraujo.santos

03-10-2007 03:17:20

Sorry, bibiteinfo your pathfinding code are used on Goof CVS code?

There is some older version that I could use? (Without pathfinding code?)

bibiteinfo

03-10-2007 03:32:59

no CVS code is ok with Ogre V.1.2, you made it work, load and save. It's GOOF + pathfinding code that work with Ogre V.1.4 in my repository in source safe which is broken due to my pathfinding, I tought it was because of some kind of obscure change in GOOF I made; I'm making calls to the terrain when it's loading the new terrain.

lstarboy

10-10-2007 10:28:52

Um what? :-) GOOF has been in ogreaddons for more than a year. That's an old version. No GOOF isn't ready.

When will new GOOF release? The old version is not compatible with the Ogre 1.4.x. :?

Falagard

11-10-2007 18:40:38

GOOF is officially canceled until further notice.

I'm not going to have people waiting with baited breath for the latest version just because the version in CVS doesn't work with Ogre 1.4. It shouldn't take more than a couple days for someone to convert the existing code over to the latest version of Ogre.

I'm still working on a new engine, but it is no longer named GOOF and it doesn't even have all the functionality yet that GOOF had when I released it over a year ago. I'm still working on getting simple loading and saving working, let alone features like undo/redo and the rest.

So don't hold your breath, it could be anywhere from 2 months to 2 years from now. Sorry.

lstarboy

12-10-2007 15:32:17

Thanks, Falagard.

bibiteinfo

20-10-2007 06:09:31

For all of you who where hoping for a stable version of GOOF, you can try my GOOF version on http://sourceforge.net/project/showfiles.php?group_id=202941

Save and load, painting and deforming are working in that version

Falagard

21-10-2007 03:15:19

For all of you who where hoping for a stable version of GOOF, you can try my GOOF version on http://sourceforge.net/project/showfiles.php?group_id=202941

Save and load, painting and deforming are working in that version


Awesome, thanks bibiteinfo!

magicstone

21-10-2007 05:43:40

Thanks falagard and bibiteinfo!

lstarboy

26-10-2007 15:28:51

Thank you very much!!!

Shtuka

07-01-2011 22:12:38

For all of you who where hoping for a stable version of GOOF, you can try my GOOF version on http://sourceforge.net/project/showfiles.php?group_id=202941

Does anyone still have the GOOF code? Can you upload it, please?

mary

08-08-2016 11:38:09

Absolutely awesome. That is another must on our list. I have just been researching trees this week. I'll take a look at this. Thanks for the updates.

*edit* It looks great! Which way are you doing the treegen? Are those billboards?