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!


Radikalizm

Member Since 05 May 2011
Online Last Active Today, 12:26 PM

Posts I've Made

In Topic: Designing a graphics programming portfolio

23 February 2015 - 02:48 PM


Metal, Mantle, DX12, GLnext, etc are The Next Big Thing™ and I wanted to get some practice in with them. A texture mapping demo won't light anybody's world on fire, but it serves as a good unit test.

 

Alright, fair enough, but just fyi I can tell you that you won't get much experience with the new APIs by doing these small demos though. I have hands-on experience with more than one of those APIs you listed here, and while I can't go into specifics I can tell you that doing these very basic things will barely require you to learn any new concepts at all within these new frameworks.

 

The whole concept of shading or texture mapping are not getting changed or replaced. As a matter of fact, you could probably even use your existing DX11 shaders on a couple of these new platforms without having to make any changes to them at all. These new APIs are mostly about the bigger picture and the optimizations which can be made by reducing driver overhead and state changes and by giving the developer more control over his/her application. The only way to really master those concepts is by having a more fleshed out demo in which you can actually play around with and see the effects of these changes.


In Topic: Designing a graphics programming portfolio

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.


In Topic: Current-Gen Lighting

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/


In Topic: Conservation Factor for Epic’s Shading Model

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.

 

EDIT:

 

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.


In Topic: Book on Physics-Base Rendering

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.


PARTNERS