FreeGameDev

How complicated would it be to implement the rendering of a 3D model in a 2D game? Is there GPLv2-compatible code available which could help with this (or learning material)?

I have been thinking of the possibility of rendering 3D models in Wyrmsun from a fixed camera position, retextured to fit in with the rest of the game's graphics.

EDIT: Looking around a bit, it looks like OGRE is what I want. I'm looking into it as I type this

It is a major undertaking to add a 3D engine to your 2D game and you don't want to have the heavy OGRE dependency just to render some simple models.

Prerendered sprites (or 3D models) also usually don't fit very well into and otherwise hand-drawn/pixelated game.

Edit: what you could do is have a look at OpenRA http://www.openra.net/ and their current work on getting the Red Alert2 voxel units into their otherwise 2D RTS game. That looks quite ok as it blends in better with the pixelated look.

Edit: have a look here: http://www.ppmsite.com/ there seems to be open source tools and sample code on that side, but I can't find the actual license info right now.

Julius {l Wrote}:It is a major undertaking to add a 3D engine to your 2D game and you don't want to have the heavy OGRE dependency just to render some simple models.

Prerendered sprites (or 3D models) also usually don't fit very well into and otherwise hand-drawn/pixelated game.

I imagine it would depend on the textures and etc.? The game "The Expendables 2", for instance, had vehicle models rendered to fit in with pixel art graphics:



Also, most the structures in Wyrmsun were first done in 3D (untextured), and then worked on to produce their final look. It seems to me that it would be possible to achieve something at least similar by directly rendering a properly-textured model.

Regarding OGRE being heavy - you mean performance impact?

Edit: what you could do is have a look at OpenRA http://www.openra.net/ and their current work on getting the Red Alert2 voxel units into their otherwise 2D RTS game. That looks quite ok as it blends in better with the pixelated look.

Edit: have a look here: http://www.ppmsite.com/ there seems to be open source tools and sample code on that side, but I can't find the actual license info right now.

Thanks, I will take a look at that!

I've heard this is called 'pixel art shader' http://initialsgames.com/main/?p=1360 However, never tried anything like that...

Regarding OGRE being heavy - you mean performance impact?

I think it's rather adding a whole engine to the game with all of its dependencies and libraries... If the game is built upon the engine it'd be fine. But in case it's just one function to call...

eugeneloza {l Wrote}:I've heard this is called 'pixel art shader' http://initialsgames.com/main/?p=1360 However, never tried anything like that...

Looks nice, thanks for sharing

I think it's rather adding a whole engine to the game with all of its dependencies and libraries... If the game is built upon the engine it'd be fine. But in case it's just one function to call...

Yeah =/ It is a suboptimal solution. Ideally it would be a library which would allow rendering of 3D models at a certain angle without having to set up a scene and etc.

I believe it's important to understand the code you're using. By the time you realize how little OGRE is doing for you in this use case you'll realize how much simpler it is to write the handful of OpenGL calls needed yourself. Engines become more important when you need to manage an entire scene or multiple effects passes, especially from a first person perspective. That said there are a lot of challenges in writing an OpenGL program for the first time. I'd be happy to contribute some starter rendering code for this if you could describe what you want more specifically. Feel free to PM me.

nnesse {l Wrote}:I believe it's important to understand the code you're using. By the time you realize how little OGRE is doing for you in this use case you'll realize how much simpler it is to write the handful of OpenGL calls needed yourself. Engines become more important when you need to manage an entire scene or multiple effects passes, especially from a first person perspective. That said there are a lot of challenges in writing an OpenGL program for the first time. I'd be happy to contribute some starter rendering code for this if you could describe what you want more specifically. Feel free to PM me.

Thank you! I sent you a PM with more detailed information

Depends a lot on how the normal 2D graphics are drawn -- if it is via OpenGL, then rendering a 3D model will be fairly straightforward, but if it is purely software rendering then it is rather more difficult.

andrewj {l Wrote}:Depends a lot on how the normal 2D graphics are drawn -- if it is via OpenGL, then rendering a 3D model will be fairly straightforward, but if it is purely software rendering then it is rather more difficult.

Both are available - there is an option (turned on by default) to activate OpenGL for the graphics, or SDL can be used for it. So it would be a matter of requiring OpenGL to be actually used if 3D models are to be rendered.

Related:
https://www.youtube.com/watch?v=yhGjCzxJV3E

Very interesting how they were able to replicate a 2D artstyle (anime) in 3D. Although, to do so they had to possess very advanced artistic skills :P

Yeah, it is really a lot more complicated than it looks at first. Did you have any luck with the voxels? That at least looks very nice in the later Westwood 2D RTS games.

Julius {l Wrote}:Yeah, it is really a lot more complicated than it looks at first.

Yeah, I had hoped that just with retexturing it would be possible to do it, but it seems I was wrong.

Did you have any luck with the voxels? That at least looks very nice in the later Westwood 2D RTS games.

I looked into the voxels, and they seem interesting, but unfortunately then we would need someone who knew how to work with them. The main advantages of including the 3D models would be being able to use models like those in OGA, to have new animations be easier to include, and to make humanoid units be able to change equipment more easily; if a significant amount of modeling (or "voxeling"?) has to be done to include 3D models/voxels, then it is probably more practical to just keep using only 2D sprites.

I did make an advance in the last couple of days though to help with animations/equipment change, which is that shield animations can now be replicated via code for human units for any shield drawn in the necessary angles (about 8), without needing to create a new spritesheet (and allows new shields to be created without need to mess with animations, which is useful since pixel art drawing and animating are different skills). My idea is to later on do that for human melee weapons as well, and then for the dwarves. But, well, I'm beginning to get off-topic here =P

'Voxeling' is quite fun and fast if you don't overdo it with the amount of voxels... it's more like 2D pixel art. But yeah, like pixel art, nice animation etc. is a pain to do. In the westwood games they used it for cool vehicles with simple animations only.

nnesse {l Wrote}:I believe it's important to understand the code you're using. By the time you realize how little OGRE is doing for you in this use case you'll realize how much simpler it is to write the handful of OpenGL calls needed yourself. Engines become more important when you need to manage an entire scene or multiple effects passes, especially from a first person perspective. That said there are a lot of challenges in writing an OpenGL program for the first time. I'd be happy to contribute some starter rendering code for this if you could describe what you want more specifically. Feel free to PM me.

Although reading in a 3D mesh, rendering with shadows (especially self-shadowing rather than just projective shadowing), handling animation, or supporting things like bump mapping are all things that I would say are far from trivial, and are things that an engine could potentially help with.

A quick look at the code suggests that it already supports OpenGL for the 2D rendering - so sticking with OpenGL would still probably be easier than switching over to a game engine like OGRE, though it's worth pointing out that doing everything yourself may still involve quite a bit of work. It may be worth checking out libraries to help, such as Assimp for reading meshes.

Another option though, if the game is still fundamentally 2D (fixed camera position), and it's just that using 3D models is desired, why not pre-render them? Whether done from Blender, or a standalone custom tool.

mdwh {l Wrote}:Another option though, if the game is still fundamentally 2D (fixed camera position), and it's just that using 3D models is desired, why not pre-render them? Whether done from Blender, or a standalone custom tool.

Two reasons basically: making it possible to adjust scale changes on the fly, and to make it easier for humanoid characters to have different equipment without needing a completely different spritesheet just because a character changed a shield.

Although reading in a 3D mesh, rendering with shadows (especially self-shadowing rather than just projective shadowing), handling animation, or supporting things like bump mapping are all things that I would say are far from trivial, and are things that an engine could potentially help with.

This was exactly the kind of code I was going to contribute. What I ended up doing was taking my material editor in https://github.com/nnesse/b2l-tools and removing all the user interface code to create a simple model viewer that uses the original B2L data and the shaders and shader parameters specified in the material editor. I pushed code for this to the repo this weekend. It's not an "engine" it's just a bit of code someone could steal to get started. The only issue on your list I haven't tackled yet is shadowing. I've implemented 3-4 different techniques in the past. I'm just not sure what approach to take that will offer okay quality but not weigh down the otherwise lightweight approach I've taken.

It may be worth checking out libraries to help, such as Assimp for reading meshes.

I am not a fan of Assimp. I tried a simple test about a year ago of exporting Blender's default box to Collada and importing it into Assimp's viewer and got a blank screen. I don't know what went wrong but that wasn't encouraging. Maybe Assimp's direct support of .blend files works okay but it doesn't support animations which is a big limitation. The needs of the application should dictate the format of the data. Having the data pass through arbitrary interchange format and middleware library just leaves unnecessary room for inefficiencies and data loss. The only kind of solution that I would want to build on would be one that involves a blender export plugin to a format that was well understood and that I could read directly from my code. For a game planning to use Lua anyways blender-to-lua is an option: https://github.com/nnesse/blender-to-lua

Yes, it'd be easier to use something already written then trying to do it all by hand (doesn't have to be a fully blown game engine, by "engine" I just meant any 3rd party code/library to do those tasks).

I agree Assimp is a bit difficult to get working. I think Blender format is documented as not fully supported, so instead I got something working by exporting to a format that Assimp did support. I'd certainly gladly ditch it for something better, but I'm not sure what else there is around. Your blender-to-lua library looks a good option.

I'd certainly gladly ditch it for something better, but I'm not sure what else there is around.

In my opinion in this case the better option is the one you make for yourself. This doesn't necessarily mean starting from scratch, you could take a known format and extend or alter it. For example if you liked JSON better than Lua it would only require a few edits to make a blender-to-json fork to cover the syntax differences. This is something I probably will do in the near future actually. Blender to lua wasn't created from scratch either, at first it was a modified version of blender's OBJ exporter.

The premise behind using a third party loader seems to be that you might be getting your models from any number of sources thus you need to be able to "support" them all. In practice however for a game development effort you're going to want to be able to modify the original models. Thus the practical value of format standardization is only that there is some loader code ready for you to use already. Then you're gambling on the blender exporter and loader having the same interpretation of the format and will possibly end up accepting some bad characteristics of format X just because it was the only one that correctly captured data Y that you needed. On the other hand a simple blender exporter can be written in less than 1000 lines of code. blender-to-lua is only 600 lines and it captures normals, tangent spaces, multiple UV layers, scene hierarchy, and skinning information.

mdwh {l Wrote}:Two reasons basically: making it possible to adjust scale changes on the fly, and to make it easier for humanoid characters to have different equipment without needing a completely different spritesheet just because a character changed a shield.

Game engines are often not particularly small packages, but some raytracers lile PovRay aren't very big. If you can convert your model to e.g. PovRay scene files, you can use PovRay to render them on the fly with paramaters passed on the command line. Your code is calling it via the command like interface, and then reads the rendered image data. Your code even can write the scene files, so you could have fully custom renders with all details controlled by your code. I've done that once with a selfmade posing tool before I had access to better posing tools ...

PovRay is open source. Ther are more open source raytracers, but I only have experience with PovRay.

These days I've got related ideas in my head to yours, and the question is to use a selfmade raytracer (I already have some code for that), or bundle something like PovRay with my project.

So far I render my sprite sheets offline. Equipment is done through an overlay system. E.g. a character has a base image, and equipment images are draw over it. Each item is rendered in 8 views. That sums up to a lot of sprites ... storage space vs. computation time is one of the usual tradeoffs one has to make.

Julius {l Wrote}:'Voxeling' is quite fun and fast if you don't overdo it with the amount of voxels... it's more like 2D pixel art. But yeah, like pixel art, nice animation etc. is a pain to do. In the westwood games they used it for cool vehicles with simple animations only.

You know, the more I think about voxels the more I think it could be a good alternative for the future, specially since they would likely fit better with the existing pixel art graphics than usual 3D models. And there's also the advantage that pixel art graphics can be "converted" to voxels by hand if there are such graphics for enough angles of the object. It could be useful for the future, for units that are currently composed of multiple layers, which could instead be different voxel objects that fit in together.

Nice

Here are some examples for easy to use & open source voxel editors:
https://github.com/guillaumechereau/goxel
http://sproxel.blogspot.com.br/

These seem also cool, but I could not find the source code:
https://ephtracy.github.io/index.html?page=mv_main
https://blackflux.com/node/11

Julius {l Wrote}:Nice

Here are some examples for easy to use & open source voxel editors:
https://github.com/guillaumechereau/goxel
http://sproxel.blogspot.com.br/

These seem also cool, but I could not find the source code:
https://ephtracy.github.io/index.html?page=mv_main
https://blackflux.com/node/11

Thank you! I tried Goxel out, and I found it quite easy to use as well.

I also found this, for rendering voxels with OpenGL:
https://github.com/sp4cerat/OpenGL-Voxel-Splatting

You could also have a look at the Red Alert 2 branch of OpenRA which should also have voxel rendering on a 2D background already:
https://github.com/OpenRA/ra2

Julius {l Wrote}:You could also have a look at the Red Alert 2 branch of OpenRA which should also have voxel rendering on a 2D background already:
https://github.com/OpenRA/ra2

I'm looking at it now... I'm not familiar with their codebase; maybe I can learn something from it but I'm not sure if I can do that just by looking at their code. In any case, OpenRA is licensed under the GPL 3.0 (instead of 2.0), so I can't incorporate any of their code into Wyrmgus either, unfortunately