Jump to content
  • Advertisement
Sign in to follow this  
Sollum

Looking for tips in 3D

Recommended Posts

Hello!

I was thinking about trying out 3D game development. Done some research.
Figgured out its more demanding that it looks.

So my initial thoughts where to try cloning existing games to some extent.
Doom (1993) or Q2.

I was thinking of using some existing world editors to build BSP maps so i could render the world quite efficiently.

And then the only thing left - to code map loader and render it in Java.

Any thoughts on this endeavor or tips?

P.S. Doom may not be 3D, but its still interesting to try out.

Edited by Sollum

Share this post


Link to post
Share on other sites
Advertisement
5 hours ago, Sollum said:

Figgured out its more demanding that it looks. ... Any thoughts on this endeavor or tips?

Yes. You will learn a lot, including an appreciation for how much effort it is. 

Note that games like this typically require multiple full-time work years to complete. The games you listed had very small teams of experts. For a team of four or five that could mean a year, but that means 8000, 10000, or more hours for people who know what they are doing.  If it is just you and you're working on it for a small number of hours each week, do not expect the same quality of work as the professional games. For five people working a full time that means a year. For one person at 5 hours per week, 10000 hours means about 38 years.

If you are re-creating games from the early 1990s and you are using some of the modern powerful tools like Unity or Unreal it can be much faster because other people have developed the bulk of the work for you. However, it will still be a huge number of hours to complete a polished product.

Good luck, and enjoy the learning process that lies ahead.

Share this post


Link to post
Share on other sites
23 hours ago, Sollum said:

So my initial thoughts where to try cloning existing games to some extent.
Doom (1993) or Q2.

...

P.S. Doom may not be 3D, but its still interesting to try out.

 

Actually - writing a WAD (Doom data container format) loader and a custom 3D level renderer from scratch is a fairly enlightening hobby project. The format is well-documented, a lot of clones already exist to do side-by-side comparison, including original source code in case you get stuck, and there's the instant gratification of actually seeing stuff as soon as you figure out how to access the level data and spit it on the screen.  Not to mention that the sheer visual gratification is doubled if you're a fan of the games.

Writing a BSP loader (the level format that Quake and co use) is somewhat more involved*.

* which is not to say the Doom level format isn't a form of binary space partitioning. I'm referring to the file extension here ;)

Edited by irreversible

Share this post


Link to post
Share on other sites

I recommend you get Blender and just start by making the scene and moving a camera around in the scene.

If you go for the classic games style you can check render engines like: http://irrlicht.sourceforge.net/

But using a engine like Unity or Unreal tends to be much easier, as they already have physics and stuff like that setup for you.

 

Learning 3D is a full time job. It takes 1 year or the basics, 2-3 years before you reach the point where you can make any object you want. Then 2 years after that to learn how to make organic models.

That means that if you plan on doing all the art for your game, you are looking at roughly spending 5 years to learn how.

 

Learning even the basics of 3D modeling is rewarding, it allows you to spot when a artist is trying to scam you and means you can to some extend help the artists.

Share this post


Link to post
Share on other sites

Hello!

Thanks for all of your responses!

My primary interest in Doom is its editors.
Editorial software should build maps with "compiled" BSP trees, so I could skip creation of those tools myself.

I am acustomed to Wings 3D, since its basic model builder.

I had done some basic 3D stuff before, but movement was limited to 2D cordinate system. I have no idea how to handle movement uphil or all the colision detection (my first guess is to split terains into smaller patches, to reduce collision detection).
How to know that your character is moving uphill just from model?

Share this post


Link to post
Share on other sites
47 minutes ago, Sollum said:

How to know that your character is moving uphill just from model?

Typically there are several representation of objects.  For terrain you often have visual models, physics/collision models, navigation meshes, and object footprints with reserved rigs and similar, along with potentially more representations.  For game objects usually there are visual models, physics models, and sometimes a navmesh footprint.  Sometimes the physics mesh is created directly from the model mesh, but often they are different.

You know a character is moving uphill by checking the terrain's physics model and looking at the slope of the physics polygon underneath it in the direction of travel.

Share this post


Link to post
Share on other sites
51 minutes ago, Sollum said:

Editorial software should build maps with "compiled" BSP trees, so I could skip creation of those tools myself.

I want to point out that BSP is old and obsolete. That is why Unreal 4 that has some of the most advanced BSP functions, constantly remind people to convert to polygons after making the basic level.

BSP is slow compared to other teck and is why some engines like Unity doesn't even bother with it. culling has replaced BSP trees and is much faster, most game engines will do the culling for you.

You can force BSP legacy mode in Unreal, but this will cut your performance down to 1/3 of what you get using the modern optimizations.

Share this post


Link to post
Share on other sites

Thanks for responses!

Happily learning 3D stuff!
Currently learning stuff about FBO, trying it out on my 2D game, for some fancy projectile effects.
Took me quite a while to get into Models and Animations on framework of my choice (LibGDX), as Wings 3D has no rigging, so i had to figure out how to manually create animations in code (later on can be scripted). 
Not planning on creating GTA 7 or something :D

Decided to try out "space" theme, as there wont be as much issue with "walking on ground uphill".

Turns out, there are lots of guides how to achieve "frustum culling" on models with ease, so i wont have to care for BSP trees for now. But one thing buggers me - How to cull invisible faces?
Thing that comes to my mind is using geometry shader to check each face if its "front" center is hit by ray? I use low poly models, up too 1500 max.

Share this post


Link to post
Share on other sites
22 hours ago, Sollum said:

But one thing buggers me - How to cull invisible faces?

Ask this question in the "Graphics And GPU Programming" forum. It is a complex topic and worthy of a discussion by it'self.

Share this post


Link to post
Share on other sites

figuring out the algorithms needed for 3d engines, and actually making a good 3d software renderer OR ancient opengl 1.x/directx9 renderer that renders the scene and particle and/or other effects will take 1-2 months. 

but then you will probably scrap the whole, and restart it to do properly to allow scalability and to not look like an ancient potato. i dont recommend to be succumbed into new who-knows-what 3d apis of the todays, as there is no point in following graphics trends any more (users will not care). and use some regular formats like obj, not obsolote and not any more used formats like bsp. and which is the most important is the game control, the phisics, basically the interaction of the engine and the user. figure out what genre do you want to create (rpg with a final fantasy like battle system? an fps like cs1.6? the actual logic will be much harder and longer than the 3d itself), and if you really start to put some time in it, you will have decent code.

you probably alreday have almost fallen into the beginners trap, and started to think ,,oh when i can fly with wasd i have almost everything done and i am the king'', meanwhile thats just a few mathetmatical function, thats not something that will need the REAL development.

if you want to keep minimalistic, i would say you can do the renderer within 2 months or so if less than 100k polygon per frame is enough, maybe 1 or 2 month to have the actual game engine logic. for quake like games you probably dont want to create an editor for the engine, and you can do everything with magic arrays or text files, so you can skip that.

you can do every code related within a few months, if you were good at maths in middle/high scool. 

but then you only created the underlying code, so you either use some tricks to generate the models (think on lego characters, or characters of minecraft), or you learn how to model in 3d properly, which will take 1-2 years, and then you either quikcly splash everything together within 1-2 months, or do it for years to have good results.

the timespan varies bethwen a very wide range, if you want to have just as decent artistic result like quake or doom has, as the others alreday mentioned, you will need years, which i expect you dont really want to push in it, as its futile aniways, the market will not honor it.

and stop meditating about culling faces, start kicking your own face until you figure it out, you will have hundreds of tasks like that to solve, and if you want to work effectively, you better solve problems like that within 2 minutes (not solving is also solving, if something is not important for your result).

 

TL;DR:

dont use complex things, dont use bsp, decide what do you want to do, do not clone doom2.

 

 

 

 

 

Edited by Geri

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!