Full 3D in RMXP -- Already Works!

UPDATE - 4/24/09
Alright guys, big goings-on. I can now successfully make 3D maps using the 2D map editor! Now, this time around it is pretty simple-- all tiles are simply cubes and the id of the tile determines which texture the cube gets. This, however, proves the validity of using RMXP to make 3D games.

Now, not only is drawing these 2D maps in 3D with my tool possible, it is also, so far, much much faster than drawing the maps in 2D using RGSS Graphics Module. In fact, during my testing I get 250+ frames per second.

Alright, so enough talk. Let's get to the awesome: *BIG Image Warning*
Layer 1 in RMXP

Don't Forget:
I still need help with art and with moral support!
Please contact me if you are a 3D artist.
If you want to offer moral support, keep posting!

Old Releases:

Third Release (RGSS Controls the 3D)

Spoiler: Highlight to view

Alright guys, now it's time to show you something really cool. I don't have a demo, but instead I have a screen shot and some real RGSS code to do with it.

And here is the magical RGSS code that does it. (Normally, you would put this in a scene, but you guys know how to make scenes so I didn't bother)

#First, let's move the 2D window out of the way:
DF_GameWindow.set_dimensions(0,0,0,0)
#next, let's create out device. The parameters are:
#Driver type, screen size (in an array), bits per pixel, and fullscreen
#This device is the central point of the 3D engine. Absolutely everything
#can be accessed through this device.
device = DF3DDevice.new(Video::EDT_DIRECT3D9, [800,600], 32, false)
#Now, let's get our scene manager. The scene manager does stuff like adding nodes
#and cameras
smgr = device.scene_manager
#Now, let's get our driver. The driver handles actually rendering.
driver = device.video_driver
#Let's get our mesh! (Note that you should probably add error handling here.
#smgr.get_mesh will return nil if it can't find the file so make sure you
#always check that the mesh was actually created. I didn't do any error handling
#but a simple check for nil would suffice)
mesh = smgr.get_mesh("sydney.md2")
#Let's create an animated scene node from the mesh. Again, normally you
#want to check for errors.
node = smgr.add_animated_mesh_scene_node(mesh)
#now, let's add a camera to the scene node! Camera are how you view everything
#in the scene. Note that it is possible to have more than one camera and
#you can switch between them, or even have them render to different parts
#of the screen.
camera = smgr.add_camera_scene_node
#move our camera, since both the camera and scene node are at the same, default
#position right now. (Which is (0,0,0)) Note that the parameters here are x, y, z.
#when your camera is at (0,0,0) and has no rotation, x is sideways, y is up,
#and z is forwards/backwards
camera.set_position(100,100,100)
#Rememeber how I said that the default position is 0,0,0? Well, since we never moved
#our node, it is at 0,0,0 right now. So, Let's tell the camera to look there:
camera.set_target(0,0,0)
lasttime = Time.now
while device.run #check if our device is still running
#begin rendering the scene. I will not explain what these parameters are yet
#it's not important right now, and it's kind of complicated XD
driver.begin_scene(true, true, [255, 160, 160, 255])
smgr.draw_all #draw all of the scene nodes
driver.end_scene #finish rendering the scene
#this junk is just so Graphics doesn't whine.
time = Time.now
if time - lasttime > 5
Graphics.update
end
end
#Now, alway always always remember to drop your device when you are done.
#The device is something you should only drop at the end of your game, after
#the device no longer runs.
device.drop

Second Release (First look at game logic)

Spoiler: Highlight to view

Hey guys! I just finished a new demo! This one allows you to actually walk around, so you guys can see that this is actually practical for making a game, and not just taking screenshots. You can also choose which renderer to use. Note that the 2 software renderers are very slow, and D3D8 does not work at all. OpenGL or D3D9 are your best bet.

I will post the RGSS code tomorrow, so you can see what it is like, but I am out of time.

Alright, first a screenshot. ON this screenshot I only took a picture of the 3D window, since you guys know it is actually RMXP (vgvgf can vouch for me, since he actually decrypted the project and looked XD)

Awesome. If anyone would do it, it would be you. I support you 100%, I might have a directional shift for you if that screenshot is anything like what you want to do.

Rather than large, almost 1st-person 3D, might I suggest using 3D for the familiar RMXP perspective? That is, third person. I'm thinking something that looks more like Diablo II than like Final Fantasy.

Formats are important, too. Can you use an existing format for 3D files, like .x or .3ds? If you can, there are already resources on the internet which could be brought into the project. If nothing else, you could use the DarkBasic 3D files and its Dark Matter expansion (both of which I have).

I would like to see good coding practices involved in this. Modularize your 3D as much as possible, and make it accessible as a component to regular RMXP games, possibly as a drop-in replacement for Spriteset_Map and the like.

Well, my plans right now actually including letting the user decide the camera very easily. I will probably provide the ability for 1st person, 3rd person high (which is what I think you are describing) and 3rd person low. ANd those would be just the 3 that are prepared for easy use. You would be able to use RGSS to do whatever kind of camera you want.

There's a long list of formats supported, pretty much all the major ones: 3ds, obj, x, and b3d to name a few. File formats won't be an issue at all

As for the coding styles, this will actually be coded in a few layers. The first layer is the C++ code for the DLLs. That code will most likely not be released, so you won't have to look at that code XD I mean, I try to keep good practices anyway, but it's not as important for that code. The next layer is where I will define the Win32API calls to the DLL functions. That's probably going to be pretty ugly. Just a hierarchy of modules arranged based on what each function does. Then the next layer is will be to re-objectify the API (Because Ruby's Win32API is rather lacking, the coding for the first two layers will be pretty much just C style coding). I will be providing a set of scripts that will provide an Object Oriented way to access the API's functions. For instance, to start the 3D window, add a node to the scene and create a camera it will be similar to:

device = DF3DDevice.new(DF3D::DT_DIRECT3D9, Rect.new(0,0,800,600), 32, true) #create a 3D device (video driver, rectangle, bits per pixel, fullscreen)
mesh = device.scene_manager.get_mesh("MyMesh.OBJ") #create a mesh from the specified file
node = device.scene_manager.add_mesh_scene_node(mesh) #create a scene node form the specified node
device.scene_manager.add_camera #add a camera to the scene
while device.run #while the device has not closed
device.driver.begin_scene #begin the scene
device.scene_manager.draw_all #draw the nodes
device.driver.end_scene #end the scene
end
device.drop #free the device after it is closed

Of course, getting it that OOP is a goal, it's just what I hope to get done. If you guys show enough interest then I will keep putting work into it.

Well, I haven't actually gotten a chance to get a numbe ron the FPS, however I can tell you the framerates are definitely decent so far. I mean, you can download it for yourself and take a look. The next demo will let you check the FPS by pressing the F key.

Hey Furdabip, thanks for the comments. Is the error you get something about a LoadLibrary error? If so, downloading and installnig the Microsoft VIsual Studio 2008 Redistributable will solve your problem. If you don't wnat to install it, you can just wait til the next demo, I will include everything you need.

Also, these first few demos will guage interest, If it looks like no one will use it, then I won't bother finishing it (I've already done the first of my goals, which is prove that the limits of RPG Maker are not as black and white as people think)

Hey meu, just for you, this is an example of code that I have actually running right now: (you may want to copy it in the script editor to see the highlighting)

#First, let's move the 2D window out of the way:
DF_GameWindow.set_dimensions(0,0,0,0)
#next, let's create out device. The parameters are:
#Driver type, screen size (in an array), bits per pixel, and fullscreen
#This device is the central point of the 3D engine. Absolutely everything
#can be accessed through this device.
device = DF3DDevice.new(Video::EDT_DIRECT3D9, [800,600], 32, false)
#Now, let's get our scene manager. The scene manager does stuff like adding nodes
#and cameras
smgr = device.scene_manager
#Now, let's get our driver. The driver handles actually rendering.
driver = device.video_driver
#Let's get our mesh! (Note that you should probably add error handling here.
#smgr.get_mesh will return nil if it can't find the file so make sure you
#always check that the mesh was actually created. I didn't do any error handling
#but a simple check for nil would suffice)
mesh = smgr.get_mesh("sydney.md2")
#Let's create an animated scene node from the mesh. Again, normally you
#want to check for errors.
node = smgr.add_animated_mesh_scene_node(mesh)
#now, let's add a camera to the scene node! Camera are how you view everything
#in the scene. Note that it is possible to have more than one camera and
#you can switch between them, or even have them render to different parts
#of the screen.
camera = smgr.add_camera_scene_node
#move our camera, since both the camera and scene node are at the same, default
#position right now. (Which is (0,0,0)) Note that the parameters here are x, y, z.
#when your camera is at (0,0,0) and has no rotation, x is sideways, y is up,
#and z is forwards/backwards
camera.set_position(100,100,100)
#Rememeber how I said that the default position is 0,0,0? Well, since we never moved
#our node, it is at 0,0,0 right now. So, Let's tell the camera to look there:
camera.set_target(0,0,0)
lasttime = Time.now
while device.run #check if our device is still running
#begin rendering the scene. I will not explain what these parameters are yet
#it's not important right now, and it's kind of complicated XD
driver.begin_scene(true, true, [255, 160, 160, 255])
smgr.draw_all #draw all of the scene nodes
driver.end_scene #finish rendering the scene
#this junk is just so Graphics doesn't whine.
time = Time.now
if time - lasttime > 5
Graphics.update
end
end
#Now, alway always always remember to drop your device when you are done.
#The device is something you should only drop at the end of your game, after
#the device no longer runs.
device.drop

The main thing with any rm is that it is significantly easier to use than making something from scratch or in something like game maker. If you're going to make a game in full 3D, wouldn't it just be easier to use a program that supports it by default instead of having to do all this crazy stuff that makes the system incredibly more complex, which in the end defeats the purpose of the maker as a whole?

For me, yes, it would be a lot easier to just do the 3D outside of RM, and infact, when I make 3D games that's what I do. I'm not making this thing for me. Also, by the time I am finished, it will be nearly as simple to use as RMXP is right now. You will still use the defualt RMXP point 'n click editors for nearly everything. You will, however, have the option of scripting your own 3D scenes. Basically, it will be really close to what RMXP is now, except in 3D. As for the problem of graphics being harder to get, I will be including a set of 3D graphics (hopefully) just like RMXP does.

Yes, all of those will be the same, or at least really close (because I may decide to add some enhancements) to the way they are in RMXP. Passability is easy, because it's just a matter of whether or not you add that tile to the list of triangles that are solid. So I can just do game_map.passability[i,j,k] and decide right then whether or not you will collide with or walk through the tile. As for events, I can actually use the exact same interpreter, and only modify the art parts of it. I will probably add some enhancements to the interpreter, though. It will be slightly (but just slightly) more difficult to work with than RMXP is now (just because I cannot modify the editors so it will take some getting used to crafting 3D in a 2D space) but this will definitely be a lot easier for most people than creating their own engine, or using an existing engine.

I can't check this out right now but holy shit this looks to be a lot of work(Maybe misplaced as theirs a lot of other maybe easier ways to go about this) and you seem to be dedicated to this. I know someone who's making an FPS out of RMXP and has done quite a bit. Apparently he's called a scripting God on some forums.

Anyway I can see the appeal of trying something not many people could even get close to but all and all it may seem wasted in the end. If you plan on making a full fledged game like this your going to need a lot of motivation and dedication to back it up. Good luck with this and I'll tell you my thoughts later.

Hehe, nah man, this is not for me to use. I am working on a game on my own, and I am just coding it in C++, I don't need to put it in RMXP XD. This is for people to use who cannot do any sort of coding and who are already familiar with RMXP.

Awesome!! I never knew RPGXP Supports 3D.
I'm thinking this took loads of free time,blood,sweat and tears (last is optional...) to make.

um.. i have 2 questions.

1- how do you make 3D characters? they look really cool

2- If you eventually made a full 3D version of of RPGXP would it be possible to
create 3D games like FFVIII or maybe a Zelda game?
(it would be awesome to see a GBA game gone 3D)
(Hmm... maybe I should make a 3D version of earthbound...)

I haven't posted in this forum yet (I'm mostly active at Creation Asylum), but I had to drop in on this! This is
really....just really awesome.

I myself am a 3rd year game art & design student and I'm using RMXP to create a level design portfolio and possibly something to enter into the IGF (Independant Game Festival). I'm using 3d Studio Max to render out panoramas and use invisible collision tiles.

Anyway, I think your project has a lot of potential and I'd like to offer my services as a 3d artist. However, as I'm sure you know, 3d modeling can be very time consuming. In order to help put together a 3d RTP for you, I would have to divert some of my attention from my current project. The only way I can see to offset this distribution of personal resources would be if I had the assistance of an, apparently masterful, scripter on my project to help relieve some of my burden.

From what I remember, colision isn't a biggy if you know what to do. To bad I don't know what to do.
2D collision works on the fact that you can only hit colored pixels, and not transparent ones. 3D collisions use more sophisticated means by using geometry, if I remember correctly, to decide if Plane QFC is intersecting Plane YOU. Or something like that.

Kudos to Seth for coining the new-most used word on the forums recently: Batshit insane
Kudos to R.A.V. for starting the spambot war
Kudos to CSC for achiveing super admin
Kudos to Egg for actually helping people
Kudos to Karl for an awsome profile pic
An

Has anyone actually had any success in implementing this into something remotely playable and interesting?
It has already been mentioned here, a few times, that ultimately it does not seem worth the trouble.

I was just wondering if anyone has found it as easy as it is being toted.
-Nick