Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 05 May 2011
Offline Last Active Today, 05:14 PM

#5226562 Interested in creating new game engine for a space adventure game; questions...

Posted by Radikalizm on 30 April 2015 - 02:20 PM

Look, you can talk about features, wants and needs all you want, but at one point you're going to have to deal with logistics and general feasibility of this project.

You're completely free to ignore the advice we give you, but you'll have to realize at one point that you'll need a large team (and means to pay them) working full time on this to make it happen. You're mashing some really difficult concepts from both game related engineering (persistent networked worlds, space exploration, etc) and operating system engineering together, and the way you're talking about it makes me believe that you don't have the required expertise in either of those.




Microsoft and sony might not like me to release a game wth that type of loophole, hut keeping it hidden in the developers console and through some code masquerading to obfuscate the intention on the platform relase could get me by.


Yeah, no. Getting your code verified on the major consoles is not a trivial task. Not in a million years would they let you run an OS which can actually access the system's hardware or which could run non-verified code in your game. I'd even be blown away if you could get any GPL licensed code through a console's verification process, due to the viral nature of the license and all.


Seriously, aim for something more achievable. Like I said before, you can still distill some interesting game concepts out of this.

#5226430 Interested in creating new game engine for a space adventure game; questions...

Posted by Radikalizm on 29 April 2015 - 11:12 PM

Interesting concept, but I don't know if you realize to the fullest how massive the scope of this project would be if you'd attempt to implement it in this form.


Is it technically possible? I'm quite sure it is

Is it feasible for (I assume) a single person without a pretty big budget to pull off? I doubt it


There's just so many aspects to this, you want space exploration, you want a first person shooter, you want persistent multiplayer, you want it to contain a freaking full linux OS with a graphical environment running inside of it and on top of that it has to be multi-platform?


Why don't you tone down the concept considerably? You can distill some interesting feasible projects from this huge concept if you want to. 

Your focus seems to be on getting some sort of OS(-like) environment to run inside of a game, why not start with a simple version of that? Getting a sandboxed shell to run inside of some game environment should be quite the challenge already. Once you have something like that up and running you can start adding stuff incrementally.

#5226352 How to learn advanced CryEngine type graphics technologies

Posted by Radikalizm on 29 April 2015 - 03:03 PM

not just looking randomly at some hard-to-read PHD type theory articles which nobody understands.


There's plenty of people who can read and understand these, and if you want to rub shoulders with the big guys it'll be in your best interest to learn how to read and understand these yourself. If you're interested in writing cutting edge graphics code it's going to be better in the long run to work on your own skills instead of asking people to spend their valuable time to dumb down content so you don't have to put in any effort smile.png



There are really no industry wide common solutions to most of the problems.


Every game is unique, every development situation is unique. Techniques have to be adapted to fit a certain scenario, therefore there generally are no cookie cutter solutions.

#5224616 Learning Graphics Development

Posted by Radikalizm on 20 April 2015 - 09:51 PM

I would definitely recommend jumping into the current API's and more specifically OpenGL due to it's cross-platform nature.


I generally don't like it when people give this advice. Yes, OpenGL is cross-platform, but anyone who has any experience with cross-platform (or even cross-vendor!) OpenGL development knows how much of a pain it is to get consistent results across platforms and hardware. I'd choose DirectX over OpenGL any time just to avoid the extension and driver compatibility hell.

#5224381 Learning Graphics Development

Posted by Radikalizm on 19 April 2015 - 05:49 PM

Is just getting in and doing something in the current APIs the best way to go?


Absolutely! The currently used graphics APIs like DX11 and OpenGL aren't going anywhere for the foreseeable future, so for all intents and purposes they're still a completely valid way to learn how to do graphics programming on PC. The upside of these APIs is that you'll be able to get something up and running much faster than with the new APIs (at least for DX11, OpenGL can be a bit of a mess when trying to get things up and running "the right way").


I think people are interpreting the purpose of Vulkan and D3D12 the wrong way; these APIs are not a replacement for DX11 and OpenGL, but rather an attempt at giving those developers who really need those advantages of being "closer to the metal" what they want at the cost of having to be much more considerate of how they design and implement their graphics framework.


If you're a novice in the area of graphics related programming these new APIs will mostly antagonize you, as you will have to deal with a lot of things which do not immediately help you achieve your goals of getting familiar with the basics. You really don't want to have to deal with doing manual state transitions, memory usage tracking and management and all the other things the driver does for you in the older APIs when you just want to learn how to get a simple mesh with some basic shaders to render on screen.


The principal concepts of getting something interesting on the screen (vertex/index buffers, textures, shaders, constant buffers, etc.) have not changed in the transition from previous gen to current gen APIs, so get familiar with the basic concepts first in a more friendly environment before exposing yourself to all the responsibilities you need to take on in the newer APIs.

#5224242 Localizing image based reflections (issues / questions)

Posted by Radikalizm on 18 April 2015 - 04:27 PM

The basic idea of "parallax correction" is used used, though juding by it you may already being doing that https://seblagarde.wordpress.com/2012/09/29/image-based-lighting-approaches-and-parallax-corrected-cubemap/ There are, as you've found, fundamental problems with using cubemaps for all the things you're trying to do with them. You can also try getting the "distance" to each object in your cubemap by tracing a signed distance field, and the above blog has some ideas on blending between cubemaps, but the basic problems of being limited to essentially projecting from the 2d walls of the cubemaps AABB will always be there. You could also try screenspace raytracing, which can be pretty cheap today EG http://jcgt.org/published/0003/04/04/ but that's going to come up with all the problems of being screenspace, and fundamentally you're always going to have errors with cubemaps.




You'll never get an accurate approximation for your scene geometry by using standard parallax corrected cubemaps. The whole idea of this is to reproject your cubemap onto "proxy geometry", which usually is either an AABB or a sphere, but of course a game's scene will almost never be made up out of axis-aligned rectangular or spherical areas.


Try to think of this approach as a way to very roughly approximate reflections, not as a solution for getting actual correct reflections for your scene. If you strategically choose locations for capturing your reflection data this will usually hold up quite nicely.


A lot of current-gen games combine this method with screen-space reflections as Frenetic Pony mentioned. For this you just determine a maximum length for your reflection ray when you're sampling in screen-space. If no sample was found you just fall back to sampling from your cubemap. This can give some very convincing results.


As for your diffuse reflection problem, the same rules for specular reflections apply, so you'll never really get perfect bounce lighting by solely using parallax corrected cubemaps. Luckily this actually doesn't really matter in a lot of cases. Due to the low-frequency nature of diffuse lighting the illusion of diffuse bounce lighting is much easier to uphold. 

I wouldn't worry too much about your bounce lighting not being 100% correct, especially if you're working with outdoor scenes. If you're working with environments where your bounce lighting will be much more noticeable (e.g. dark indoor scenes with smaller splashes of bright light) I'd recommend you look into different approaches to solving this.

#5223787 Glossy reflections - how to do a proper blur

Posted by Radikalizm on 16 April 2015 - 02:32 PM

Have a look at this presentation by Epic, they show how they deal with IBL for their shading pipeline in Unreal 4


Slides: http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf

Course notes: http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_notes_v2.pdf


They do a split-sum approach where they encode one part of their BRDF data in a lookup texture and the irradiance data in an importance sampled cube texture. Every mip level of this cube texture represents a different roughness level, so you can achieve these rough glossy reflections.

#5223281 Direct3D 12 documentation is now public

Posted by Radikalizm on 14 April 2015 - 06:33 PM

I don't understand the purpose of the CommandAllocator object.
It cannot create 2 lists (at least if they are live at the same time), it doesn't have a lot of member function, and I didn't find any equivalent in Mantle programming guide.


The command allocator object holds on to the memory it allocated for generating a command list, meaning that it can construct similarly sized command lists after an initial command list has been reset without having to do any new allocations. Managing command allocators correctly is crucial to reduce overhead related due to memory allocation. It is also crucial to be aware of the size of the command lists you allocate on a certain command allocator as the memory maintained by an allocator will otherwise eventually grow to a worst case size.


It might be tempting to make a pool of command allocators and just request a free one when you need to generate a command list, but this will cause D3D to hold on to way more memory than needed for command list creation.

#5223185 The best place to find research papers

Posted by Radikalizm on 14 April 2015 - 11:42 AM

Is there any good place to find research papers with user reviews or ratings!


This should be a good place to start: http://jcgt.org/


Lots of game studios provide publications on their websites as well. The benefit of those is that those techniques have already been battle-tested in actual published games as opposed to lots academic research papers. The concept of "interactive framerates" has a different meaning to academics as opposed to game developers.

#5223183 HLSL being strange

Posted by Radikalizm on 14 April 2015 - 11:33 AM

Ah yeah the input.normal has zero length. Strangely when I replace that with a float3(0,0,0) it doesn't bug quite the same way. Anyway, I've used a clamp() around dot() like unbird advised.


Thanks, closed.


Hint: If you need to clamp something in the range 0.0 - 1.0 have a look at the saturate intrinsic instead of clamp.

#5221939 What exactly is a file header?

Posted by Radikalizm on 07 April 2015 - 03:16 PM

Thank you, frob! That is a very detailed and informative explanation. I do have one question though... All the different types of data that you mention that can be stored in the header, can all this be declared inside a struct and written normally at the start of the file just like the payload data? Please clarify. Thanks.


That's pretty much how that would work, yeah. Fill out your header struct in your code and just write it to the beginning of your file. At read time you just read in this struct again from the beginning of the file and you're good to go

#5212501 Designing a graphics programming portfolio

Posted by Radikalizm on 23 February 2015 - 01:08 PM

The thing with graphics programming or any game programming on a resume is more about presenting a fully workable system. If you want to do something with graphics, animate a bunch of characters in a busy city and have them with an avoidance system and make some shaders on some cars etc. Seeing something like this as opposed to a wall with tessellation applied or a demo of a single character animated in your code, is a big difference. Plan to build something that has a purpose. Find some free models, like from turbosquid or elsewhere and come up with an idea for a scene. If you have ever seen the nvidia demos when they release new graphics cards, they have small scenes with characters animated and some other background stuff going on.


I completely agree with this. Implementing the individual items you mentioned in your OP is something you could easily achieve by just following a bunch of tutorials, which is something any relatively skilled programmer can do. If you want a demo which stands out you'll have to show that you actually grasp the concepts you mentioned and that you know how to use or modify them to achieve a certain desired result.


At my current position I mostly do rendering, and it never comes down to building just these simple techniques which could be found in tutorials, if that were the case there'd be no need for dedicated rendering engineers at all. Instead it comes down to being able to achieve a certain visual style, system or technique within the constraints set up by the project you're working on (be it performance, style, target audience, etc.). Like any software engineering position it comes down to problem solving and knowing your toolbox inside out so you can solve your particular problem in the best way possible.


So yeah, learn the techniques you mentioned and build something with them which achieves a certain goal you've set for yourself. That way you can show your potential future employers that you have the skills necessary to solve problems instead of just being able to reiterate something you memorized from a tutorial.

#5198498 Current-Gen Lighting

Posted by Radikalizm on 16 December 2014 - 04:10 AM

I also like the FilmicGames blog by John Hable.


As far as I know he stopped posting on that blog, his new page is at http://www.filmicworlds.com/

#5194319 Conservation Factor for Epic’s Shading Model

Posted by Radikalizm on 23 November 2014 - 03:18 PM

Is it correct to use just the Fresnel (from the light’s point of view, hence L•N, not V•N) or should it include the distribution/geometric terms as well? I tend to think these are typically ignored for performance, but for the moment I am more interested in accuracy.


As far as I understand it the diffuse term should indeed take surface roughness into account in some way. Applying the 1.0 - F trick is to account for the trade-off between diffuse and specular at glancing viewing angles, but is not a completely accurate approach.


Naty Hoffman has provided some references for this stuff in her "Physics and Math of Shading" SIGGRAPH course notes: http://blog.selfshadow.com/publications/s2013-shading-course/hoffman/s2013_pbs_physics_math_notes.pdf


Have a look at the bottom of page 20.




It's also always possible to just have a look at the shader code provided in UE4. I have the source lying around here somewhere, but haven't looked into their shaders too much yet.

#5194229 Book on Physics-Base Rendering

Posted by Radikalizm on 23 November 2014 - 12:24 AM

Do you know of any books on real-time raytracing that helpful?


When we're talking about OpenGL we're in the realm of rasterization, not ray tracing. Certain aspects of ray tracing are starting to become common in traditional rasterization-based renderers (screen-space reflections are a good example), but even though actual real-time ray tracers do exist they're generally still quite slow and not viable (as far as I know) for applications such as games.