Jump to content
The Dark Mod Forums

GameDevGoro

Member
  • Posts

    283
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by GameDevGoro

  1. You know what though? There are those specially built lanterns that have like the back covered in a reflector plate thing that allows the light to be reflected in one direction? Maybe one could make such a lantern as variation or something? Doesn't have to be modern.
  2. I haven't seen it pulse, unless you've(not you specifically, but the dev team in general?) changed it just recently. And yeah, I was talking about having it shimmer in brightness so that the lit area isn't constant. Having it move around isn't necessary. Does the flickering and strobe of existent light effects work within the confines of the light's radius or does any one of them change the radius at all? (Maybe altering the range isn't such a good idea....)
  3. Is it possible to make it flicker like the candles? That could add a lot of atmosphere in certain contexts, make it look less rigid. The light, I mean. Edit: Used a weird word, tired braaain. :I
  4. There will be, but I've only built the start of it and I've planned the next "area" so to speak. I'm a little tentative as to how I will end it. It's a tough one to write an unfolding event that actually seems significant, otherwise you'd get that feeling: "All this for THAT!?" But I've got a few things going, and it's really inspiring to see all the awesome work Bikerdude did on this one and the responses in this thread.
  5. My Wikipedia-skills say "Heavily-modified Unreal Engine 2".
  6. Games don't nowadays often release editors and other tools unless the game is "sandbox". I doubt that Arkane will release tools for Dishonored. But that depends: They didn't release tools for Dark Messiah, knowing that it's built with the Source engine. They released the source code for Arx, since it's their own tech. Does anyone know what engine Dishonored is using? Also: This thread isn't about Dishonored, I know. But it seems this thread hit a tangent anyway so. Excuse me. Furthermore: Am I completely wrong or do I remember that Thief 4 actually uses the Unreal engine?
  7. Oh dear lord... Somehow I'm still extremely disappointed, even though I never anticipated that much from Thief 4. *sigh* And seriously, that really feels passive aggressive: "No more hiding in the shadows". Because that was so the thing I hated when I played Thief. Another display of what happens when you've got your head up your ass.
  8. That is so cool every cavity in my head is drooling.
  9. This is a bit fascinating. Could this be "Authority" (or its ilk)? But sorta... "Stylized"?
  10. Nope. No compute shaders. Just standard approach with plain ol' vector math. (My engine is also targeted for DX10 hardware so, compute shaders are DX11.) Oh. I don't actually use an accumulation buffer in that regard. I don't really see the point nor do I think it really applies in my situation. All of the lighting right now is blended additively onto the rendered scene, doesn't matter what light it is, deferred, forward or just emissive term. Works fine for me. Though for a pure deferred approach this isn't a possibility since to my knowledge you wouldn't have anything to blend it on per se. As far as I know, a pure deferred approach has ALL of the data in the GBuffer and doesn't leave anything rendered "traditionally" in the backbuffer. So realistically, if you just turn on additive blending and draw the light results you get nothing, it'd just blend the lighting onto the clear color and you'd just see your deferred scene rendered on top of that (again, with no lighting). But I draw the lights after I've drawn the ambient term into the backbuffer, which means that when I draw the light results it just blends with the ambient pixel that's already there. So I don't really need to bother with a light accumulation buffer, I just render the deferred lights as I do the forward rendered ones, with the same blending. Unless I've totally misunderstood what a light accumulation buffer is for, and in that case, please enlighten me if you can. A pure deferred approach is of course better in the regard that you really do just draw every piece of geometry once per frame, I realize this. But it also makes it more limited and in order to gain more control over how things are rendered you'd end up creating more buffers. More buffers = more memory and bandwidth consumption. Hmm not currently. But it's "upgraded" from just using constant, flat ambient values to using a diffuse cubemap. This way one can emulate sky and ground pretty efficiently, getting the reflected colors from the general atmosphere in the dimples and cracks of the normalmap. (looks TONS better in my opinion) (Bonus: I'll also admit this idea popped into my head the first time I watched the Overgrowth videos ) I really should support baked ambient though... Maybe I'll put that in, won't take that much work.
  11. Absolutely. I have enough draw passes to deal with on the material side: cubemap reflections, emissive term, fresnel term and a few more things. In a very worst case some models tend to draw up to 5 times because of different material passes that get applied to them. I'm actively looking for ways to minimize this, but I'm also aware that not all of the rendered geometry needs to have all the material passes applied. Combining shaders is probably a good start. I expect that for all generalized geometry that only need normalmapping, specular shift and gloss draw 2 times at most. Once for ambient fill and one more time for GBuffer.
  12. I'm intrigued by this "surface quality" you speak of. You shouldn't technically get any surface quality degradation unless you use formats that are of lesser bit range than you require? For example: using 8 bits per channel on the normal buffer has banding artifacts whilst 16 bits per channel hasn't. Point being, if you manage your buffers neatly then there's no visible difference with forward lighting and deferred. Well, it's not Light Indexed. But yes, I use scene depth to reconstruct the positions of lights, using linear depth(not exponential) as to not compromise floating point accuracy at long distances. And since this depth is stored linearly I can also use this buffer for soft particles and depth fog in water and other neat stuff.
  13. Well. Directional lights are in fact forward rendered. How I do it right now is I draw ambient first, then directional light blended onto that. None of these are ever put into the GBuffer. The GBuffer only contains diffuse color, normal direction, specular shift and some things in the alpha channels like specular gloss and linear scene depth. Does that make sense? I fear we may be speaking of two different things here then... I'm talking about lights that only have a direction in 3d space, no location. No location = no possible attenuation. Everything gets lit equally from this one direction. But regarding the LOD for lights, that would work actually. But I'm not sure if it actually would be faster in the end. It's all about scene complexity, not wanting to draw a 56k triangle character more than once.
  14. @OrbWeaver: That's absolutely correct, but to my understanding sometimes it can be a transparent film or something with silhouette pictures on it that is placed in front of a light. Old school zombie movies used these for shadows from tree branches and things. Or I could be remembering it all wrong, that has happened before. The basic idea is still the same, something that obstructs a lights path, creating "controlled" shadows. @nbohr1more: Well. Right now, all of the lighting is deferred except spotlights that cast shadows and directional lights. The choice to put directional lighting into forward rendering is based on the idea that directional lights always affect everything in the scene equally as it has no falloff. It's slower to invoke the deferred shader onto the entire screen for something that can just as well be put in before the actual deferred shading begins. I know that people who are interested in a "pure" deferred renderer frown at the idea of this, but I don't. It makes perfect sense to me. I will also at one point replace shadowing with deferred shadowing, simply because it's a bit of a pain to deal with shadow-casting spotlights separately. Now for your second question... I'm a bit confused by what you mean by "light projection"... :S
  15. Well- I've seen it used in the 3d quite a few times (cinema and 3d do cross paths in more than a few areas). It's not really technically correct, I guess it's more of a simile to the real thing? I feel it's close enough to what it's supposed to simulate so I stuck with Gobo. I can't say I'm specifically familiar with theater lighting and such. My knowledge is more general, but that generality fortunately covers these things too, so I'm not completely in the dark. (I hope)
  16. OooOOoh snap, people. (For someone who didn't check out my status update this might be a fairly confusing topic.) D:
  17. The current one looks a bit odd, posture wise. Stiff. The new one has a hunched over back which definitely looks more like running to me. So I vote for the new one...
  18. You'd need at least one height map for each surface that use it, yes. Furthermore, using parallax mapping puts some increased pressure on mappers to properly align textures so the parallax effect can really do its job well. Otherwise it runs the risk of just being one of those things that most people say look like crap. TDM (and Doom3) already gets enough flak from people saying it looks plastic. Edit: But I can't really say for sure, just speaking out of experience here. Wonderful things can be done with it, as with any graphical effect...
  19. Yeah this has to be one of the worst things I've seen in a long time.
  20. I used to play with Legos a lot when I was younger... But then I gradually replaced it with building stuff in 3D on the computer instead.
  21. Aaaaaw yeah, Noss. Painkiller is bad assery in a bucket. I love it. Hard Reset looks interesting, I'll have to dig deeper into it. Thanks!
  22. No it didn't try to be Doom, that's not what I meant. But you said it with your Duke Nukem example: that is what I meant will happen to new Doom games, simply because the idea doesn't fly anymore. People are going to expect too much and in turn be disappointed at the loss of their own conceptions.
  23. Alright yeah. But you get it right? Younger audiences are the majority who buy games, always have been, always will. But that audience doesn't define "old school" the same way... Maybe that's their strength, though. Because I've seen kids enjoy those cheap mobile platform games that are just carbon copies of Dig Dug or Boulder Dash and such. They just don't know that those games existed WAY before their inception on the mobile game market. And in the case of Doom4. I'm sure some kids out there would enjoy it if truly is as mindless and straightforward as Doom. But look at Bulletstorm. No one even talks about that game today, and it tried being old school. So is that what Doom4 is doomed (pun) for, 15 minutes in the spotlight (literally) then everyone just forgets about it? In fact even RAGE went over similarly. No one barely plays that game anymore even though it's a decent shooter. *shrug* Maybe everyone will love it.
  24. It is... Just a few days after the rumor surfaced a developer on Doom4 (I think) shot the rumor down. Well. What I really meant was that: The idea doesn't hold up because people expect more from video games today. I'll be damned if anyone can make a game that functions like Doom today and get good reviews, scores or whatever it is people care about. Imagine. You start the game, select a difficulty and in you go. No intro cinematic or anything- you just hop right in and start blasting guys left and right. I'd for sure be entertained, but would the energy-drink drinking 12 year old CoD player think so? Not likely. It simply doesn't go around. I guess if it truly is old school, targeted at the old Doom fans and sold at half price from the get go, the maybe. It's a sad time for old school games. A kind of genre in which game like Doom, Quake and Hexen soared.
×
×
  • Create New...