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!


jammm

Member Since 18 Mar 2013
Offline Last Active Apr 01 2015 01:35 AM

Posts I've Made

In Topic: Technical papers on real time rendering

24 February 2015 - 06:26 AM

 

 

wouldn't it make more sense if you find one or more interesting papers from those journals and implement them ?

Taking existing/available implementations, adding a couple of references and submit them as your own research is NOT how you get a degree...

It's not really research, just a presentation. As I said, it's just a seminar. Nowhere in the post have I specified that this is research.

 

 

The following advice is if you're genuinely interested in learning here, if your priority is to pass the seminar as simply as possible than I guess you disregard it.

 

The point of these exercises is typically to have you research a topic you're unfamiliar with and show that you're capable of picking up knowledge and understand what's going on on your own (by crawling through refs, etc...). The post 2012 criterium is probably there specifically because most pre 2012 algorithms have simple tutorials or at least sample projects available that you could copy, or which do a large part of the "understanding" for you and give it to you in a simpler and more digestible manner, at the cost of depth and accuracy. 

 

That may not seem like a big thing, but if you're unfamiliar with it, there's quite a difference between crawling papers to understand and implement something, and reading a tutorial and implementing what's presented there. But paper crawling is important if you don't want to wait around for others to explain stuff to you when new papers come out. Just as an example, most tutorials you find will go fairly easy on the math and pretty much always sweep something under the rug that's extremely important to get a detailed understanding of the relevant field, as opposed to just that specific algorithm that's presented in a tutorial.

 

Also it's kind of lame to implement something like the basic SSAO algorithm that Crytek came up with when lots of improvements in that area have been made since.

 

But now, some practical help: This thesis from 2013 is a pretty good overview over some relatively recent advances in SSAO (it compares six specific algorithms).

 

I agree with you, I do intend to learn from implementing these algorithms, but the reason why I'm going for a simple-to-implement algorithm is so that I could first learn how that works, then implement a paper which improves upon that algorithm. Also, I only have a month to prepare for this, so I have to be realistic with my own goals and expectations by the end of the month.

 

Thanks for the thesis link! I'm sure I'll be having a great time going through it, understanding the algorithms and, if possible, implement one of those algorithms as part of my demonstration!

 

 

 

Regarding DOF/Bokeh: you should most definitely check out this presentation from CryTek (from 2013), and possibly also this 2014 presentation about COD: AW. In my opinion, the purely gather-based approaches are more scalable in terms of performance, and can give some really great results. The first presentation also has some good references to earlier papers that you can check out.

Thanks alot for the links! That's some great information right there smile.png

I also found a paper here, which talks about an advancement in DOF/Bokeh, offering better performance than normal non-seperable filtering. It seems to be cited in the Crytek presentation too. The plan is that I'll be learning DOF/Bokeh from your samples, implement them on my engine and try to implement this paper after that. I hope you don't mind me referencing your approach while implementing DOF/Bokeh on my engine.

 

I'll be sure to cite your blog and the paper I found on my report.


In Topic: Technical papers on real time rendering

23 February 2015 - 09:48 AM

wouldn't it make more sense if you find one or more interesting papers from those journals and implement them ?

Taking existing/available implementations, adding a couple of references and submit them as your own research is NOT how you get a degree...

It's not really research, just a presentation. As I said, it's just a seminar. Nowhere in the post have I specified that this is research.


In Topic: Becoming a game engine programmer

18 January 2015 - 11:36 AM

 


Right now I'm in my Junior year of undergrad, and I haven't really made any mods of any game so far, though I did tinker around with the Quake 2 gameplay code for a bit, which was quite fun. I also liked the Wolf3D mod scene, and played around with the level editors when I was a kid
 
So, currently I'm learning graphics programming, and already at the level where I could get a basic 3D scene up and running with lighting and textures. But your insight has raised a question in my head - should I continue learning graphics programming? Or should I just work on game/gameplay programming instead for my portfolio, then learn graphics/engine programming while working as a game programmer?
 
All these options sound really exciting, that's why it's difficult for me to make a decision.

It's hard to give advice because we're not in your situation, and our situations won't necessarily apply to yours biggrin.png

 

My general advice is that by the time you graduate, you should have at least a small standalone-game or a total-conversion-mod, or a collection of small mods, or a research project demonstrating a new innovation. Generally I would say that you should have made this in your own time (not schoolwork) however there's always exceptions, e.g. many "game schools" allow you to do a large group project during final year, which often results in quite an impressive/large game... or if you're doing a thesis you might have some great innovation/research to show off.

 

In your case, if you're interested in graphics, then making a small game (even an 80's arcade game remake) would be great if you can say that it's running on your own graphics framework instead of an existing engine. In an interview, you can then have deep conversations about how this framework works.

 

It's usually short-sighted (and frankly a bit sociopathic) to base decisions just on the state of the market, but at the moment, there is huge market demand for graphics programmers. e.g. I have companies in the USA offering to double my salary if I wanted to move to that country and do senior graphics programming work. So assuming that this demand sticks around, that's a good incentive to follow your interest and keep learning in this area.

It's hard to get into a graphics job as a junior/graduate, but you might get lucky if you're in the right place and the right time. Otherwise, it's always a plus to have on your resume if you're trying to get a junior/graduate gameplay programming job - it might make you stand out more against other candidates if you can write gameplay code but also have demonstrable knowledge of graphics stuff. It means if they invest the time in taking you on, then they'll have the option of moving you into the engine team later. It's nice if in an interview you can express an interest and show a bit of knowledge in engine/tools/tech-art areas as well, to show your value as a generalist and a strong self-learner.

 

So basically, try to learn gameplay and graphics if you're interested in both wink.png

 

All right then, I've decided to continue with learning graphics programming, making my own graphics framework in the process, and create a working demo game using that engine/framework before I graduate.

 

Thanks a lot for the advice! I will always keep it in mind to motivate myself smile.png


In Topic: Becoming a game engine programmer

18 January 2015 - 12:29 AM

@Op - how did you get there?
I'm a graphics/engine programmer. I did mod programming as a hobby on the GoldSource engine for 4-5 years, until I'd basically read and tinkered with every line of gameplay code behind HalfLife 1. At that point I was a fairly decent game programmer and level designer, which is important as game programmers/artists are the clients of engine programmers - and a business that doesn't understand the needs of their clients is doomed to fail.

About here I started writing my own engine as a hobby.

Then I got a job doing game programming on Unreal, then a job doing tools programming at a company that wrote their own technology. Then because I knew what a shader was, I was able to transfer internally to an opening on the graphics engine team, and end up doing customisation on top of Gamebryo. Then I got a job at a big games company as a special effects programmer (using their proprietary engine) so I got to see what being a game-side (not engine-side) graphics programmer was like.
Then I applied to be a game programmer again, but going by my resume they assumed I was applying to be an engine programmer and they put me in their engine team, where I ended up being in charge of rewriting their low level APIs, and implementing game-specific effects.

This whole time I had still been building my own engine as a hobby. By now it was quite packed full of features and contained lots of code... But here I abandoned it. All my new professional experience made the underlying architectural flaws too obvious to ignore now. So at this point I started on my own engine again ;) and now I'm making an Indie game with it and licensing the engine libraries.

Thanks a lot for the insight! It's really very appreciated biggrin.png

Right now I'm in my Junior year of undergrad, and I haven't really made any mods of any game so far, though I did tinker around with the Quake 2 gameplay code for a bit, which was quite fun. I also liked the Wolf3D mod scene, and played around with the level editors when I was a kid biggrin.png

 

So, currently I'm learning graphics programming, and already at the level where I could get a basic 3D scene up and running with lighting and textures. But your insight has raised a question in my head - should I continue learning graphics programming? Or should I just work on game/gameplay programming instead for my portfolio, then learn graphics/engine programming while working as a game programmer?

 

All these options sound really exciting, that's why it's difficult for me to make a decision.


In Topic: Becoming a game engine programmer

17 January 2015 - 02:29 PM

What do you think an engine programmer is?

 

Game development studios are nontoriously fast-and-loose with their titles. An engine programmer at one studio may be focused entirely on graphics, in another studio they may be focused on core technology like memory management and crash reporting, in still another they may do some combination of both, or may be the programmers responsible for the shared technology across all games whereas "game programmers" are working on specific titles (even if both programmers do the same basic work in the same basic domains).

 

So what is it you want to do? That's more important to the issue than what you want to be called.

Thanks for replying!
Now that I think of it, I guess it's graphics programming that I'm interested in, though I don't mind working on other core technologies (probably not physics and a maybe for networking) but I find my interest mostly in the rendering engine right now.


PARTNERS