Jump to content
  • Advertisement

Lutz

Member
  • Content count

    459
  • Joined

  • Last visited

Community Reputation

462 Neutral

About Lutz

  • Rank
    Member
  1. Lutz

    2008 Retrospective and progress

    Seriously, me and my coworkers are having bad trouble talking about your stuff. Couldn't you've picked a name more like Steve or something? What does that name mean anyway?
  2. Lutz

    IBL: Incredibly Bad Luck (tm)

    Oh no! That's the end of Adam Offline! :-(
  3. Lutz

    Rant and depth-of-field

    Why does motion blur only apply to the parts of the terrain that are further away? No, seriously, excellent work so far, but one thing: With DOF, terrain looks unrealistic IMO - like it is in a 2x2 meter sandbox. It reminds me of old movie tricks with models that looked unrealistic since they had too much depth of field. I haven't worked out the maths, but I guess when you focus something that is 1 km away, the stuff in 10 km does not have any visible DOF effect in reality, since the ratio of focal length to distance to the object is so small. That's different when objects are smaller and closer.
  4. Lutz

    It's coming.. !

    Quote:Original post by roel Quote:Original post by Lutz Can I have a 64-bits-per-channel version uncompressed of this picture (meaning that each r, g and b is stored as double number). I've developed a deblurring algorithm in my PhD thesis. Just want to test it... How can that work? A blur is a lowpass filter, isn't it? How can you restore the information you filtered out by blurring? If you store the result as double numbers, you don't loose (much) information. If you quantize it to 8 bit and store it as JPEG, you loose a lot and can't restore anything.
  5. Lutz

    It's coming.. !

    Can I delete a post btw.?
  6. Lutz

    It's coming.. !

    Can I have a 64-bits-per-channel version uncompressed of this picture (meaning that each r, g and b is stored as double number). I've developed a deblurring algorithm in my PhD thesis. Just want to test it...
  7. Lutz

    Shadow mapping & misc. work

    Did you consider using stencil shadows or is it infeasible for some reason? The reason why I ask is that shadows in space are usually very hard since the sun is quite a point-light and there is no scattering distributing the light. Stencil shadows are always nicely sharp, even if you zoom in very closely. I doubt that shadow maps do a very good job here since the scales of a space station are still very different.
  8. Lutz

    Ambient occlusion

    Isn't this a very rough (1-pass) radiosity approximation?
  9. Lutz

    Back to programming

    Really, that bug is a very nice one! In a nice-bug-list, it would surely be in the top-10. Did you set the pack alignment or was it an ODE flaw? In VC, it's possible to put the pack alignment on a stack, should be something like this: // Store #pragma pack( push, oldPackValue ) // Set value to 1 #pragma pack( 1 ) // Some includes etc. // Restore #pragma pack( pop, oldPackValue )
  10. Lutz

    Detail textures, step 5

    Oh, you can't do that! This is not fair! No, honestly, with some nice trees, it's photorealistic. Terragen in real time. Maybe I can be a better "competitor" in near future...
  11. Lutz

    Terrain integration, step 2

    The depth haze in the first image amazes me. The transition from terrain to atmosphere is very smooth. In my own project, this was not so good. Is this a by-product of the exponential scaling of the colors or did you apply some special hack to achieve this?
  12. Lutz

    Z-Buffering issues

    Quote: Lutz: that's an interesting idea. But your example works for 2 planets. Let's say you have to display 20 planets (like in the Jupiter system): are you going to split the z-range in 20 segments ? To solve that kind of problem with z-clear, i was thinking of determining the planet's area in screen-space, and only clear that part of the screen. The 2-planets example was just to give the rough idea. In a real scenario, the idea has to be worked out a bit. Considering the 20 bodies Jupiter system -- If you want to make it real (i.e. the proportions of all bodies and the distances to each other), then the bodies are either as small as dots (so you don't really need z-buffering) or there are at most 3 or 4 visible (with a moderate field of view). So you'd have to check how many planets are larger than a spot and only for those do the depth range stuff. You could even make an own z-range for the "dot-bodies" and draw them all into this z-range (call it "infinity-range" - that would even fit to the name of your engine ;-).
  13. Lutz

    Z-Buffering issues

    There is a possible solution to the z-fighting problem that does not require clearing the z-buffer all the time. You can set the depth range for each planet differently. Here's an example where you have 2 planets to render. For the planet that is further away set glDepthRange(0.5f,1.0f); and the zNear/zFar as you do it now. For the planet that is closer to you set glDepthRange(0.0f,0.5f); and again the zNear/zFar as you do it now. That way, you only use 1 bit precision, so 23 bits are left which should be enough. You can also record all z-ranges prior to rendering and assign a depth range to each z-range that balances the precision for all objects (also spaceships). That way, you don't need any z-clear and the z-values are always meaningful.
  14. Lutz

    Improving terrain textures

    The second one looks really good. How do you plan to do the detail texturing? If you plan to do 100 layers for the global terrain, it does not matter, I agree. But if you plan to do one genuine detail texture for each global layer, it makes things more complicates since you can't blend 100 textures. You could solve this by storing per patch the four/eight layers with the greatest weights, though... Moreover, from my experience, the resolution of a global weight texture (i.e. a map that tells you "here is rock and there is sand") won't be high enough if you go to ground level - even if it's 1km per pixel. You could disturb the layer weights by noise, but the result won't look very good since for example the rock at steep slopes will "bleed" into the low-slope regions. Also, the detail texturing won't fit to the "Perlin-noisy" landscape.
  15. Lutz

    Terrain texturing

    Quote:Original post by Ysaneya - upsampling using bilinear filtering: when differencing the heights for the normals, the derivatives are not continuous -> lots "grid-based" artifacts Did you try bicubic interpolation? At the four boundaries you'd have to store the respective adjacent rows of vertices, too, so that you can calculate some derivative values for the interpolation. So you'd have to store a 35x35 field instead of 33x33 per patch. But then, you'd be able to generate a smooth interpolated heightfield where also the normals are smooth (that is, continuous but not differentiable... normals would be as if bilinearly interpolated, phong-like). Remember the two example heightmaps I once sent you, one with bilinear and one with bicubic interpolation?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!