Author
Topic: How about OGRE3D? (Read 6161 times)

It may be good idea to switch to this graphic engine because it already implement features that we need to do anyway, such as camera and particle. I dont think I can handle all 3d work as I'm really not good at it. This engine was written by professionals and many real game use it. We have great posibilities if we use it =)

Well if you do run into any roadblocks with OGRE or your own 3D engine the forum at GameDev.net has a lot of great resources. Everything from DirectX programming, OGRE 3D, to post production. They are even starting forum classes, the first one being an intro into C++. I've seen a lot of cool projects come from the OGRE engine. The "Your Announcements" section previews many of the current projects with free demos. From just looking at the OGRE wiki, it looks as though it has many of today's top notch visual features as well.

First if we tie ourselves into one engine, then we are tied to that one engine. (DOH!)

How about we use an interface class, just the same as we used for the File System (I've been trying to get subversion working all day.. LOL)Essentially we EXPORT data generically to whatever system the classes are designed for.IE// add characters too the battle sceneBattleModelType *Character;// tell the battle model it's Character1 (IE the first character in the party)Character = new BattleModelType(Character1);// Set the engine for the character to put data into// Quake3 engine or OGRE for exampleCharacter->Engine = BattleSceneEngine;// load character data and convert to an internal formatCharacter->Load();// convert this model data into the battle scene engineCharacter->Export();OR something like that .. that is a bit over simplified obviously.

You will have to use OGRE in orthogonal mode for field scenes. This is because backgrounds have no perspective correction since they are 2d layers. The perspective correction will need to be done at some interval to scale the models correctly. In the Battle Scnes perspective correction can be used because these are wholely 3d.

In any case the field scenes will be hard to display in OGRE or Q3's engine. In OpenGL you can switch the mode as you draw so using our own engine would work just fine in that case.

I suggest worrying about the 3d stuff a bit later really because we aren't even close to that part yet.

What do you mean that it would be hard? You can use glOrtho for the field, and then use your standard drawing for the models.

Or, push a new projection matrix on the stack and then pop it when you want the models.

I mean it's not plug and play. More importantly with just GL (if you read carefully) it's easy. With an engine, it's not so easy.

Now the thing is that you have 2d layers and a walk mesh. Somewhere in the field file information is what describes the placement of the 2d layers relative to the walkmesh and when what gets drawn.

In summary you have a number of layers, PC and NPC model information to analyze before anything gets drawn. The ordering of the drawing changes depending on where the PC/NPC is on the walkmesh, and the positioning of the 2d layers. This is not easy especially in a large scene with a bunch of NPC's. If it were one could just throw it together in a few minutes

What do you mean that it would be hard? You can use glOrtho for the field, and then use your standard drawing for the models.

Or, push a new projection matrix on the stack and then pop it when you want the models.

I mean it's not plug and play.Â More importantly with just GL (if you read carefully) it's easy.Â With an engine, it's not so easy.

It's easy. People use engines not to make things harder, but otherwise to make it easier. We need a lot of things that we need to write by ourself aside of GL. Frame limit is one of things thet needs to be created. Console for runtime script debugging, All shading and camera work.The most hardest are all video cards support. We need a lot of hacks to make them all works correctly and fast, there are a lot of bugs. Engine solve all this problems.In addition Ogre can use DirectX render which is faster under windows.

Quote

Now the thing is that you have 2d layers and a walk mesh.Â Somewhere in the field file information is what describes the placement of the 2d layers relative to the walkmesh and when what gets drawn.

In summary you have a number of layers, PC and NPC model information to analyze before anything gets drawn.Â The ordering of the drawing changes depending on where the PC/NPC is on the walkmesh, and the positioning of the 2d layers. This is not easy especially in a large scene with a bunch of NPC's. If it were one could just throw it together in a few minutes

2d enviroment is not a problem =)Read the manual to Ogre =) More importantly that 2d and 3d already works correctly and tested by many users. If we use our own render it will be a lot of bugs. There are to small amount of developers to work on all this things. We need to concentrate on the game itself, not on the one of the hardest things - 3d engine.

It's not problem with ether engine or my abstraction from open gl (the model is loaded into inner format and then we works whith it as one). On lower level they do the same things.

The 3d part of the engine is not that hard, the rendering is actually a painters algo with 2d layer overwrites. This seems a little overkill for what we need. When we get to the battle system, there might be a call for something a little more complex, but most of the stuff off the bat is kernel file support and 2d rendering.

Keep all the modules seperate. There is no need to put 3d code into the menu system, which should be the fist module up and running. The field system reads 3d entities for display from the dat file. These are all-in-one models (though you have to piece them togeather) with modular, sharable animation sequences. There is no need for another engine overhead.

3d battles are more long term, and even then, we have a debug battle to parse and play with, (battle 999)

In the end, we should be able to make each compoent of the engine stand on it's own, with very very little interaction between modules execpt for a place for the call to start and a place for the call to end.

In the debug room, when you call battle 999, the battle module is called and the whole field module is deleted. The only thing that the battle module reads is the savemap, (The menu module is also deleted) and the battle number that was used as an argument. Everything else is kernel hooks. When the kernel is finished, The display, animation, and window routines should already be in place in the kernel. We don't need another engine to manage this for is.

Leviathan can load models without a huge engine behind it.Ifalna and render animations without any huge engine supportZangan can display battle locations (By the way, the battle backgrounds are the same format as all the other polygon enities in the game)

I think this will lead to overengeering, and overengeering leads to fear, and fear leads to suuuufffferrriiiinnnggg!

sfx1999:Ummm enhancements weren't a goal originally, and likely still aren't in other words enhance after it works.The fact is.. enhancements are WAY down the road, these are features and aren't needed for the project to meet it's goal.

It's going to take a bit of time to get objects for reading both types of content. (PS1 and PC)I'm in a six of this half dozen of the other view on this. However I do believe it's too early really to implement anything for an engine.For now we can discuse what will work

There are plenty of ways to implement 3d etc. I'm really not in a big hurry to use anything in particular myself. We've got plenty of time to think about it.

First goal is to have something working for debugging the script engine, kernel, and loading things in.We aren't there yet so it's OK to think about it but... I see no point in discusing what enhancements are to be made when we have nothing to work with.

Akari:You make some good arguements it's something to think about. I was looking at the Q3 engine. If you've played RTCW it seems that engine is quite capable of handling menu's etc. Maybe you can look into it?

halkun:hehehe.. well yes I was kind of saying "interface" to get off the engine thinking and into how to we get what we have to work with something else I'm not sure if an engine will make everything easy, since I've not used one before (grin). However I would like to point out that dismissing something because it's overkill is not a prudent way of looking at the problem. First we aren't there yet, Second it might be good to decide just how do we want this part of q-gears to work. I'm wondering if we build an interface with the ability to use more than just our own custom engine we might be better off (it's more generic at the very least and thus portable). Just in the same way we are handling 3 types of content (PS1 CD, PS1 ISO Image, PC data) the GUI can be handled.

I suggest we look at 'engines' in general find which ones we can use for the project (IE legally) and which ones make our job of handling the modular construction easiest without it becoming overly dependant on engine features. Lets do some research while we implement things that have to be implemented now. When the time comes "to engine or not to engine?" we can decide after thinking about it some more.

I am not for or against using a 3-D engine, and likewise I am not even for or against this project in general.I am here to state facts.

#1: sfx1999 hit on a point I was going to make some time ago.Modular design is a great idea.Following the original gameâ€™s design to a tee, making only one module loaded at once, is a terrible idea, and it was a terrible idea when they did it too.The only reason they did it was to fall within the memory constraints imposed by the system. We donâ€™t have these limitations on modern computers (or even older computers than back then).

#2: I donâ€™t particularly see the need for using an existing game engine. In the most rudimentary situation you still have to hack together some form of compatibility between Final FantasyÂ® VIIâ€™s file formats and the game engineâ€™s expected formats. Speaking from experience, once you have loaded the model data (which must be done manually in either case), it isnâ€™t exactly difficult to add the one extra layer of drawing triangle strips.Remember, Final FantasyÂ® VIIâ€™s model formats are so proprietary, you still have to handle the bones and animations entirely manually, after loading the models manually.Creating the compatibilities with the engine is most likely more work than just making your own, especially considering all the research into how to actually create those compatibilities.

It is really not much work to create the graphical aspects of Final FantasyÂ® VII.

As I said six of this half dozen of the other (IE it's a 50/50 split).It is a concern to have to spend time making an engine work, inspite of it having all sorts of features.Hence I've repeatedly said interface because no matter what happens how the modules deal with each other in an orderly fashion will make or break what we implement.We can't change the original content to fit the engine. We can convert it and load it in real time. Most engines use a different model format and structure. I don't know if the skeleton animation system of FF7 is even remotely compatible with existing engines. Between FF7 and FF8 the model system is quite different. So yes it won't be easy at all.From my work on FF7 models etc. it IS verifably easier to make something to draw the original content, than to use an engine.

My view is we can use an engine later, as for now it's like beating a 1 penny nail with a sledge hammer. Gross effort and makes a mess.

Whatever we do it will take work, there is no easy way to do it honestly. Hence I'm in no hurry to make things more difficult now

I believe OGRE has interfaces for different models, or it can be done a different way, but converting on the fly is an option.

Also, I think OGRE has frame limiting built in. You only really need it for the bike race, and you really could just use some kind of hack for that.

I'm not positive but we want frame limiting to be switchable on and off. With a default set for 30 FPS field and 15 FPS battle. 60 FPS menu. This I believe is FF7's default setup. Minigames I think were run as seperate binaries (IE like loading a battle), so they had to back interface into FF7 kernal.. halkun? Thus they ran at there own FPS (internal to the game basically). This is why on the PC there is the incredibly fast bike race issue

I'm sure OGRE supports lots of models BUT that's not the problem, as FF7 uses NONE of those and more importantly it's a non trivial task to convert from it to another format. The animation and model data will require considerable work to convert.

Nothing is easy bottom line. Why am I saying this? Because I've tried it with GLscene and it wasn't a simple matter to convert the format to anything else.

Nothing is easy bottom line.Â Why am I saying this? Because I've tried it with GLscene and it wasn't a simple matter to convert the format to anything else.

If you want to knew - OGRE support opengl-like polygon creation (begin, end, vertex, color and so on) and can internally convert all of this to inner format - very easy, you know =)By the way. Our engine will use inner format too. There are no way to handle this without specific format, and I'm sure that our format will be worse than prophessional. There are a lot of people who work and test it for a long time. We just dont has resource to do things that way =)

I think this bickering is getting redundant without a vaiable soultion.

Let's worry about this later.

Right now the only real module on the table is the menu. This subsystem reqires no massive engine to move a little finger to select varibles. (The menu system is a little more complex than that, but in the end it's a 2D system.) We should worry about this when it's time to parse the field script and we have to render an entity on the screen.

If it becomes a challange to render an overhead view of cloud and yuffie in the STARTMAP debug room, then we can persue technologies needed. As for now, the loading of window.bin and maybe a text test should be in order.

Each module should be as orthogonal as humanly possable. This is a rule I'm holding steadfast too.

Orthogonal code: from the Pragmatic Programmer

Quote

"Orthogonality is a critical concept if you want to produce systems that are easy to design, build, test, and extend. However, the concept of orthogonality is rarely taught directly. Often it is an implicit feature of various other methods and techniques you learn. This is a mistake. Once you learn to apply the principle of orthogonality directly, you'll notice an immediate improvement in the quality of systems you produce.

What Is Orthogonality?

"Orthogonality" is a term borrowed from geometry. Two lines are orthogonal if they meet at right angles, such as the axes on a graph. In vector terms, the two lines are independent. Move along one of the lines, and your position projected onto the other doesn't change. In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface. Before we look at the benefits of orthogonal systems, let's first look at a system that isn't orthogonal.

In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface."

Mixing our dependincies is going to cause havac. All calls must be handeled though the kernel, not to a supporting lib that has it's hands all over the codebase. It's a bad concept and I don't like it. If you want to add functioanlity, add it to the kernel. This is going to be the basis for adding other modules and supporting other games then FF7. You want to make FF9? You will have to rewrite the fieldscript system a little, but the kernel calls should be the same. That the kind of modularity I'm looking for. Graphics is handled though one module, the kernel, that's it. The text boxes are rendered with it, the text is drawn by it, the 3d models are popped out by it.

Q-gears *is* an engine. It's silly to think we are writing an engine with an engine. You guys are talking about step 689 and we are on step 4. I'm going to guess by the time we need the technology to do what we need, it most likely will already be there.