I want to learn planet rendering. I searched a little and found some information on LOD algorithms but I can’t begin with that (it’s too big for a first 3D approach). I’m a good C++ developer but I’m a pure noob concerning OpenGL (I think DirectX is not free so maybe I should begin learning with OpenGL, (even if it’s not a good lib according to @INovaeKeith) ?), 3D development in general (even If I also tried some things on it) , shaders, etc…
I want to learn how but I don’t want to spend years because of bad searches or advises or because of poorness of french tutorials treating on all theses subjects… and I don’t know how to correctly explain what I’m searching for, so there is an example of answer I’m searching :
"1: follow this link -> the best and simple OpenGL Tutorial
1: Don’t use OpenGL, use directly DirectX and learn about it here -> link, book, etc…
2: then read this and see this video for shaders, etc…
3: look here to learn how to code on gpu
4: for LOD Algori…
thanks a lot in advance for the time you’ll make me win.
DirectX is free, just like OpenGL. As the title of your post suggests I’m afraid you have a very long ways to go before you’ll be ready to tackle planet rendering. You can find everything you need for learning on the internet via Google. @JB47394 provided a good link to DirectX tutorials. If you still want to use OpenGL then I recommend http://nehe.gamedev.net/.
I think DirectX is a better solution to start learning computer graphics than opengl, i can say this because i started with Opengl and now i regret the time that i lost because of it being my starting api to learn. DirectX is a better organized sdk versus opengl. To simplify it, DirectX covers almost all aspects of game dev, like graphics, sound, input, shaders, compute shaders etc, with opengl you are only covering graphics, you will need to integrate other libraries for rest of the tasks. 2ndly for learning computer graphics/game dev in general the best way in my opinion is to start with a top down approach alongside the bottom up approach and crush the complexity in the middle. With top down approach i would recommend the use of some game engine and i would specifically recommend Unity3d Game engine to learn computer graphics and game dev, alongside which learn DirectX sdk which is going to be your bottom up approach.
For DirectX you can also learn it from Rastertek.com and learning resources for Unity3d are at the click of a wishful google query search button (in other words plenty). Hope this helps.
However, always remember that even the longest journey starts with a single step. Everybody, even the most amazing 3D programmers in the world started where you are now. In fact you probably have an advantage over most of them due to the wealth of freely available tutorials and problem solving advice that is now available on the net.
Thanks for all theses answers it helps me to keep motivation even if the way is difficult.
@Crayfish your reply is something true that I don’t use to think as I should. I’ll try to keep it in mind.
Can somebody describe the main steps that come after/in parallel of/ learning DirectX ? I spoke about most things without knowing what I’m talking about… it’s really important to me to understand the global scope/way before going into detail. I suppose that a lot of knowledge is hided before each pixel and,without even searching to reach the I-Novae engine level, I want to see in detail every steps to obtain a significant result (aka 10% of infinity’s detail xD)
If nobody can, thanks again for your first answers.
I also have a last question : Open GL portability is still a good argument, If I have to be cross platform, no other choice ?
About that, does I-novae plan to be playable on PS4 or PS5 ^^ or DirectX choice doesn’t permit it ? (OK now i’m done with questions…)
My advice would be not to build your own game engine as a amateur game programmer, it’s probably the worst thing possible to do IMO, so forget about DirectX. You don’t need to go that low to make a game in today’s age.
If you want a lowish level experience go with XNA or MonoGame, otherwise try using Unity. Make something in one of those engines and then decide what level you wish to code on.
I think the only major problem you would have with using an existing game engine is that they don’t come with a 64bit depth buffer, but there are ways around that. And you would have to implement that yourself anyway, going the custom route.
Even if using an existing engine is a problem, you will learn a lot just by making a first iteration of your planet generation algorithm in one of the existing engines. INE has been re-written a handful of times.
If you wanna write a planet renderer a high level aproach is unlikely to cut it to get planet rendering in real time require rethinking almost everything you do as almost no game use that kind of scale
also to contradict somehting that’s been said earlier i would advise against unity it’s rather limited and as far as i know it does not realy allow thinkering with it’s inner working wich will be necessary at one point or an other I would instead suggest taking an open source game engine that you can dissect to your liking and adapt to your needs
also a 64 bit depth buffer mostly impossible as generaly consumer level gpu don’t even handle 32bit depth buffers most you can generaly get from consumer grade hardware is 24 depth + 8 bit stencil
I don’t see a fundamental problem with scale except the depth buffer constraints, Unity also allows you to go to shader level and grants access to compute shaders. What exactly would you need to rewrite on the engine level that makes planet rendering impossible in Unity?
As for the depth buffer, Frontier’s Cobra engine and INE both simulate/emulate a 64bit depth buffer when the card does not support it.
MonoGame is opensource and would allow tinkering with the inner working of the engine.
@kamui, make anything related to planet rendering in any engine, you just have to start. The field is somewhat addictive…
I decided to begin this morning, and I already encountered a problem : the openGL tutorial @INovaeKeith gave me is for Windows only, and my portable is on Ubuntu. I’ve also a PC with windows 8 but I’d prefer learn on Ubuntu, with an OO API instead of an horrible Win32 API . Is there tutorials as good as “nehe” ones ?
For the approach, I hesitate between Unity and OpenGL (and you don’t help me ! )… I like to see “how it works” but I’m also wondering if it would not be more interesting to me to know how to use Unity if tomorrow I want to work on game development… there’s not a lot of game studio that still have a bottom approach so I really don’t know what to do…
I want to learn something to make planet rendering (the procedural way), because I love the thing that you create something without really knowing its final appearance (like a baby ^^). I also want to create games since I was a kid so I want to learn the most useful for this… I made a lot of little games in 2D, and I know how to make a big game in only 2 dimensions, but I have to overtake that and know how to do it with three (and then 4… and then 11 )
@cybercritic I didn’t write a line of code and I’m already addict, it’s so awesome
Beside depth buffer general handeling of objects is impossible with just 32 bit
Even the earth is to big for the surface to be properly positioned.so there is not only the depth buffer that need reworking alot of the pipeline does
No i’m generating them proceduraly as needed but the issue was negligible until i started enabeling orbital mecanics it’s hard to explain but in short when your planet move the vertices will move from one possible float value to the other sometimes making hudge jumps that look like hickup and deform the mesh.
KSP is the closest it can get but even ksp 1/10 the scale and it’s likely the maximum that can be done without extencive modifications the several Space Kracken issues are a sympthom of this limitation.
So your position uses a float and you basically overflow that float, a float is just not large/precise enough to cater for your system position needs? We had a discussion about this on the old forums, you need to “zone” your system, so scale down to make the positions further apart, then that problem goes away. However that also means that the rest of your system wouldn’t fall into your current single zone, and for that you use logical tricks.
Hope that helps.
You should be able to get 100m position resolution from LEO with a float.
Please note that the screenshot I just posted is of a 1:1 scale planet Earth in KSP. Space Krakens are more often symptoms of NaN arithmetic and timewarping through SOI changes (as mentioned, anything much larger than a planet does suffer significant issues).
Hm, alright, I’ll bite. I started with and still use OpenGL. Can’t speak to DirectX, but API won’t matter for this summary. Disclaimer: I’ve built a procedural planetary renderer, up to but not including the least-recently-used cache (LRU) and geometry occlusion (although I’ve prototyped both). So my prototype will generate and render a whole planet at once, to a reasonable level of detail - but I’m limited by polycount since everything displays every frame. At that point, life become a bit more interesting (namely I was deployed to Afghanistan), and work on the project stopped.
I think, besides learning directx, you should get an idea about 3d graphics are organized in general. Vertices, faces, normals, shading,…
I collected some knowledge about this by reverse engineering the level file-format of Tony Hawk’s Pro Skater… After that I implemented a rudimental path tracer (which is actually a very nice thing because it is easy to implement)
After that, I still have no idea of directx or opengl. But I know how 3d graphics work in general