Hall Of Famer
Member
Ricoman":3pwohu62 said:
Are you saying there is a way to import 3d models to RMXP using this engine? If so, I can get my tile artist to begin working with blender right now.
[On hold indefinitely] Full 3D in RMXP
- Thread starter DeM0nFiRe
- Start date
- Status
Are you saying there is a way to import 3d models to RMXP using this engine? If so, I can get my tile artist to begin working with blender right now.
These will be the supported mesh formats http://irrlicht.sourceforge.net/feature ... tedformats
Hall Of Famer
Member
DeM0nFiRe":1waftulc said:
Thanks a lot, man. Another question, in 2d games we simply add the 2d tiles to a large tileset in RMXP, so what can we do about the 3d tiles? I dont think it is possible for us to add 3d tiles to a tilesheet, so how can we load the tiles(say in .3ds format) to the actual game itself? I'm curious.
Hall Of Famer":1yoi09l7 said:
uhm, Demonfire, how did you want to do the tileset bit? are you wanting like 3D tiles of grass, water etc or will it be more like making a 3D landscape (not chopped up into tiles)? I know things like trees and bushes will be tiled, but I thought the terrain would be made more like Morrowind, where it is continuous not a bunch of tiles stuck together...?
idea: can you make it so the maps are malleable? By that I mean where in the editor you can make certain vertex points moveable to shape the landscape more organically?
Hall Of Famer
Member
Hall Of Famer":104oa8hg said:
Can someone please answer to my question??
Hall Of Famer
Member
DeM0nFiRe":zizj23i4 said:
I think you could have been a little bit nicer. I am seeking for information, not flame. Please keep your mouth shut if you are not interested in answering questions.
Anyway, I will direct my 3d tile artist to this thread. Hopefully he will be able to contribute something to the project, and yes, he is making a .3ds file right now.
I'm coming back with a few more questions here... :p
First, obviously, I wonder if you have any intentions to work on a VX version. I don't think it should be too much of an adjustment (well, depending on how you translated the tilemap data...), so yeah...
Second, I've been wondering if you plan on creating a complete 3D engine, or if you'd try to support character sprites as well. That's a topic I'd instantly work on as soon as I'd be seeing some code from ya, so work on it yourself if you don't want me to put my hands on it ^^ (either way, only if you make a VX version :p )
In relation to that, I wonder how your camera's set up. Judging from the demo game, you have a position (x, y, z), along with a direction (an x,y,z target?). In that case, I'd figure you'd set that target to player coordinates as soon as there'd be an actual player character to focus the camera on, huh...
The other way I could imagine you doing it would be using angles (like, rotate camera 40° on x, 35° on y and 12° on z). Thinking a bit ahead, this might be easier to work with for non-scripters trying to adjust their camera later on, but harder to work with in scripts... (especially a sprite-based one)...
Also, I wonder what your plans regarding modelled environments are. I'm talking about cliffs and all that, but while complete 3D maps would be fancy, I think it'd be cool to instead have placeholder tiles for models.
Meaning, you place tile #12 of your tileset somewhere. That tile can store images of knights, cars or porn as far as we're concerned, because it'll be replaced via script with a 3D model that's perfectly cubic in it's outlines. This could be some cliff tiles, for example - modelled beforehand, like this:
I think you can see where I'm going with this. And yeah, that's all the poly you need for this size really, since anything else can be done with the texture (hint on the people posting models in here that, while showing skill, are too high-poly for their purpose).
While modeling this, I've been wondering if you'd include displacement mapping, since that'd sure be something neat to have :p
EDIT: I forgot to ask - for those 3D tile-mapped cubes you have, are you going to include any way you can assign textures to top and sides that are different from each other?
Also, I'm not worried about if, but WHEN I'll be able to take a look at the coding
First, obviously, I wonder if you have any intentions to work on a VX version. I don't think it should be too much of an adjustment (well, depending on how you translated the tilemap data...), so yeah...
Second, I've been wondering if you plan on creating a complete 3D engine, or if you'd try to support character sprites as well. That's a topic I'd instantly work on as soon as I'd be seeing some code from ya, so work on it yourself if you don't want me to put my hands on it ^^ (either way, only if you make a VX version :p )
In relation to that, I wonder how your camera's set up. Judging from the demo game, you have a position (x, y, z), along with a direction (an x,y,z target?). In that case, I'd figure you'd set that target to player coordinates as soon as there'd be an actual player character to focus the camera on, huh...
The other way I could imagine you doing it would be using angles (like, rotate camera 40° on x, 35° on y and 12° on z). Thinking a bit ahead, this might be easier to work with for non-scripters trying to adjust their camera later on, but harder to work with in scripts... (especially a sprite-based one)...
Also, I wonder what your plans regarding modelled environments are. I'm talking about cliffs and all that, but while complete 3D maps would be fancy, I think it'd be cool to instead have placeholder tiles for models.
Meaning, you place tile #12 of your tileset somewhere. That tile can store images of knights, cars or porn as far as we're concerned, because it'll be replaced via script with a 3D model that's perfectly cubic in it's outlines. This could be some cliff tiles, for example - modelled beforehand, like this:
I think you can see where I'm going with this. And yeah, that's all the poly you need for this size really, since anything else can be done with the texture (hint on the people posting models in here that, while showing skill, are too high-poly for their purpose).
While modeling this, I've been wondering if you'd include displacement mapping, since that'd sure be something neat to have :p
EDIT: I forgot to ask - for those 3D tile-mapped cubes you have, are you going to include any way you can assign textures to top and sides that are different from each other?
Also, I'm not worried about if, but WHEN I'll be able to take a look at the coding
Well, this whole thing I am doing actually has 3 steps.
The first step, of course, is to take over the RGSS Player's window so I can do what I need to do with it. That step is pretty easy, and is relatively the same for both XP and VX (For XP, I have to create a 2nd window and hide the first. For VX, I can just play around inside the first window.)
The second step is to write the interface to let RGSS access the functions of the Irrlicht, the 3D engine. This is exactly the same in XP and VX.
The third step is to create the scenes in 3D. This is not the same for each, particularly the map scene is very different. In terms of scriptability of the map scene, VX really takes a huge step backwards because of the way tilemaps and tiles work now.
What this means, is that I plan on releasing the 3D SDK itself for both XP and VX, but I do not plan on creating any scenes for VX meaning it will be up to you guys to create the default script set to go with VX.
That being said, the 3D SDK portion of this is meant for advanced scripters. I have no interest in limiting the freedom of use the advanced scripters have so that less advanced scripters don't have to learn more :P The default scripts for XP will provide a good way for users to see how it works in action, but that's about as far as I plan on simplifying it on the scripting end. On the point n' click end it will, of course, be sufficiently simple that it should be usable for just about everyone.
As for the tileset, yes that's basically how it will work. Each tile on the tileset will correspond to a model that fits in a rectangular prism. (I plan on setting no limit on the Y, just on X and Z)
As for displacement mapping, definitely not :p I may include normal mapping/ parallax mapping but that's about as far as that will go :p
As for the tilemapped cubes, that was just a debug thing and it does not reflect what the final product will be.
The first step, of course, is to take over the RGSS Player's window so I can do what I need to do with it. That step is pretty easy, and is relatively the same for both XP and VX (For XP, I have to create a 2nd window and hide the first. For VX, I can just play around inside the first window.)
The second step is to write the interface to let RGSS access the functions of the Irrlicht, the 3D engine. This is exactly the same in XP and VX.
The third step is to create the scenes in 3D. This is not the same for each, particularly the map scene is very different. In terms of scriptability of the map scene, VX really takes a huge step backwards because of the way tilemaps and tiles work now.
What this means, is that I plan on releasing the 3D SDK itself for both XP and VX, but I do not plan on creating any scenes for VX meaning it will be up to you guys to create the default script set to go with VX.
That being said, the 3D SDK portion of this is meant for advanced scripters. I have no interest in limiting the freedom of use the advanced scripters have so that less advanced scripters don't have to learn more :P The default scripts for XP will provide a good way for users to see how it works in action, but that's about as far as I plan on simplifying it on the scripting end. On the point n' click end it will, of course, be sufficiently simple that it should be usable for just about everyone.
As for the tileset, yes that's basically how it will work. Each tile on the tileset will correspond to a model that fits in a rectangular prism. (I plan on setting no limit on the Y, just on X and Z)
As for displacement mapping, definitely not :p I may include normal mapping/ parallax mapping but that's about as far as that will go :p
As for the tilemapped cubes, that was just a debug thing and it does not reflect what the final product will be.
Well, I guess I don't mind doing the map engine if the 3D base is there... actually, that would make it even more versatile for the game designers and less samey on every game there'd be :p
So yeah, all that being said... I'd help ya out, but all I can do 3D-wise is doing lazy tile models in half-an-hour lunch breaks ^^" (not that I wonder what you need models for if you donT plan on releasing a ready-to-go-package either way...)
Ah well, I'll watch your every step in this thread definately though, and since I'll throw in one or the other random idea, I guess that counts as moral support :p So yeah, keep up the good work!
I have no idea what you mean by that, but you probably meant 'no limit on Z, just X and Y', didn't you?DeM0nFiRe":2nk9xrc3 said:
So yeah, all that being said... I'd help ya out, but all I can do 3D-wise is doing lazy tile models in half-an-hour lunch breaks ^^" (not that I wonder what you need models for if you donT plan on releasing a ready-to-go-package either way...)
Ah well, I'll watch your every step in this thread definately though, and since I'll throw in one or the other random idea, I guess that counts as moral support :p So yeah, keep up the good work!
No, I meant no limit on Y, only on X and Z. If you are viewing the scene from a logical observer's position (a person standing on the ground) Z is depth, X is width and Y is height. That means from a top down perspective, the Y you are used to in 2D becomes Z. This is the coordinate system that Irrlicht uses.
To get used to it, hold up your left hand and point your index finger away from you. Then, point your middle finger to the right so it makes a right angle with your index finger. Next, point your thumb up so that it is perpendicular to the plane created by your index and middle fingers. Now, each of your fingers is pointing in the positive directions, Z for index finger, X for middle finger and thumb for Y.
To get used to it, hold up your left hand and point your index finger away from you. Then, point your middle finger to the right so it makes a right angle with your index finger. Next, point your thumb up so that it is perpendicular to the plane created by your index and middle fingers. Now, each of your fingers is pointing in the positive directions, Z for index finger, X for middle finger and thumb for Y.
Now that seems to be just illogical for me, working with x/y-ground-based coordinate systems in 3DSmax, autoCAD, SketchUp and countless level editors for years now XD But yeah, I guess it doesn't really matter what's it called as long as it's working :p (still imagine it being kind of hard to get used to for the simple fact of ground coordinates then being stated in x/z :/ if I'm not getting you wrong...)
BlueScope":1mhk3y69 said:
I am certified in 3D animation, specialized in Maya 8.0, have a AAS degree in AutoCAD, certified in Catia V5 and have been involved in the 3D community for over 15 years. I have NEVER heard of X-Y being the default plane for ground. The only time that EVER happens is when you customize the view icon arrows to flip the Y and Z planes.
Before calling people "illogical" stop and try some logic for yourself, first. If you can't figure it out then look it up. Books are your friend.
Well, first of all, cool down, man... I meant no offense at all >>
Other than that, my close-to-default installations of 3DSmax and AutoCAD both give me X/Y ground planes, so yeah... that's all I know. I'm always happy to have people around telling me that I should've looked up something that seemed perfectly valid to me though, so thanks.
Other than that, my close-to-default installations of 3DSmax and AutoCAD both give me X/Y ground planes, so yeah... that's all I know. I'm always happy to have people around telling me that I should've looked up something that seemed perfectly valid to me though, so thanks.
I don't know what is going on with your defaults then, but industry standard is as I said in my previous post. Do you have legitimately purchased software or is it some kind of hack/crack? That could be one explanation. Check your defaults and see if you can change them, it would help if you're going to be working on this project with Demonfire. Every model you send him will have to be altered and rotated to work with his other models.
As for the intensity of my post, I have just had way too many ten year olds come into these forums and scream about how they know everything cause they heard it on the internet and they've spent a whole year working with this software and that software and now they think they know everything. It wasn't meant as a personal affront; I was seriously saying that you need to look into what is standard in the industry before you go off about how you know exactly how things should be.
:cheers:
As for the intensity of my post, I have just had way too many ten year olds come into these forums and scream about how they know everything cause they heard it on the internet and they've spent a whole year working with this software and that software and now they think they know everything. It wasn't meant as a personal affront; I was seriously saying that you need to look into what is standard in the industry before you go off about how you know exactly how things should be.
:cheers:
First, You guys are both tools. Don't argue in my thread.
Second, you're both being silly. There's an infinite number of possibilities for ways to organize your coordinate space. There is no real one industry standard, because there are really 4 different systems that are used equally as often. Left and Right hand systems with X/Z or X/Y Planes The engine happens to use This left-hand coordinate system The left hand rule with X/Y ground plane is equally as common as with X/Z ground plane, but this engine uses X/Z. It is conventional for the artists to change their program's settings to the engine's configuration, because it is silly to have the engine do the conversion.
Second, you're both being silly. There's an infinite number of possibilities for ways to organize your coordinate space. There is no real one industry standard, because there are really 4 different systems that are used equally as often. Left and Right hand systems with X/Z or X/Y Planes The engine happens to use This left-hand coordinate system The left hand rule with X/Y ground plane is equally as common as with X/Z ground plane, but this engine uses X/Z. It is conventional for the artists to change their program's settings to the engine's configuration, because it is silly to have the engine do the conversion.
- Status