Skip to content

Latest commit

 

History

History
221 lines (211 loc) · 14.1 KB

TODO.md

File metadata and controls

221 lines (211 loc) · 14.1 KB
Raw

:: Plan for the CS 557 Final Project ::

  • setup a large quadrilateral for the base

    • will do water, and land

  • setup something for the sky? point cloud maybe

  • Windows setup

    • with GLMan, can auto gen basic layouts quickly
    • entropy comes GLMan rand...somewhat okay

  • Mac setup (more work but it's what I want)

    • with OpenGL, I have to setup the quad by hand
    • then fragment shader will work as expected
    • entropy comes from whatever we setup outside..., and we have control over that entropy
    • don't have to lug around the external-drive

  • Fallbacks in case you have problems generating terrain (water should be okay)

    1. Terrain should be loaded via noised texture
    2. Use GLMan with same shaders, and utilize noise texture to generate better land stuff

:: TODO ::

  • cleanup the final project, isolating the large quad code we made (retain experimental shader code, cite attribution if you use it!) ~ move as much graphics logic into Special OpenGLMB class
  • move camera on top of the quad
  • scale up the quad
  • implement some basic random height map in vertex shader, verify we have enough density to make land
  • make a dense quad that is actually a square...
  • verify base fragment shader coloring works
    • implement color by height
  • implement per-vertex lighting (pull from last assignments loaded in flip)
  • implement a continuous noise function in Vertex Shader
    • use this to generate a basic heightmap
  • smooth the heightmap using the mix step function, as in it should smooth out on the edges
  • in fragment shader color red above a point & blue below a point in the graph
  • perturb normals based on wave function to give basic water animation (try later)
  • Add step function to gradually shift color for hills until it maxes out at white for the top
  • Implement a single sheet above, color with faded coloring to look like clouds
  • improve terrain generation with modified fbm
  • improve terrain lighting by adjusting normal based on surface position
  • improve terrain coloring by using a series of mixing
    • mix green to brown to white
    • green -> brown 0.0 - 0.3
    • brown -> dark brown 0.3 - 0.8
    • dark brown -> white 0.8 - 1.0
  • improve water quality by applying fbm there as well, with light coloring
    • as separate sheet
  • set water with high specular highlight
  • mess with normals on water (will give concept of waves..)
  • wasn't able to discern how to make 'breaking' waves, which would have been nice
  • try to make white water in a 0.01 color mix
  • improve cloud quality by coloring with respect to S and T (make them super smooth okay!)
  • improve cloud quality by applying vertex displacement as well
    • increase density of sheet or scale it up (and clouds) by quite a lot
  • also perturb normals on this to make it look like the water, but slightly different, with clouds
    • compute normal by calculating 2 points slightly off, and then compute cross product to get normal
  • Polish this and see how it looks (pretty amazing)
  • If time consider a volume for cloud
  • If time consider physical wave displacement as a 3rd sheet that intersects the land, and is separate
    • means discarding the other section of the land as we work
  • try to use the same cloud logic code to add shadows in the land
    • then we're done
  • done, write up the report now
  • ((extended work, volume clouds))
  • create a box
  • create sky_vol.frag & sky_vol.vert
  • pass in the initial position and dimensions
  • need to get dynamic camera position relative to surface coord, probably need to pass that in unless it's available in the shader?
    • needed ECPosition, which is in Eye Space, making the camera at <0,0,0>
    • using this for what I key off of to read values in the frag shader is what works based on camera position
  • determine the eye position, and the following vertex position
  • as it stands just picking surface items
  • try discarding for vals < 0.0 or w/e
  • pass in volume start coordinates as uVolumeCords (passed in)
  • perform matrix mult to adjust old volume start coords to new camera cords
  • pass these along to the frag shader as vESVolumeCords (adjusted to eye space)
  • step the current position in Eye Coordinates along with small intervals until we hit outside the surface
  • calculate distance between point inside and outside the surface
  • use this to calculate our intervals for N steps
  • loop again, collecting values for each step interval
  • combine and use, or discard if no value
  • try and work it out
  • try to fix 1/4 screen rendering, wtf is going on there?
    • seems the scale coordinates got halved somehow? (system related potentially)
  • looks to be working, but it's far too obvious on the bounding box
    • hypothesis...slowly drop the color as we get close to the edges, so the boundaries can't be seen
    • test this for a simple thing other than fbm, like a small glowly sphere centered at the position in the middle?
      • still with raycasting, but we don't care, we'll exit out anyways
  • fix box to 0,0,0
  • test with sphere in the middle for raycasting equation
    • purpose is to determine if we are casting rays as intended
    • sphere is not showing up for somet reason
  • buggy raycast works, but the coordinates are incorrect for some reason?
  • try with increased definition, just to see how it looks
  • coordinates seem to be 'stuck' based on old vMCPosition stuff
    • check where vMCPosition comes from

check Eye coordinate setup for static appearance (looking for 3Disms)

  • almost, just a probe however (in camera space, makes sense...)

  • try water effect on the EC stuff too (as a long sheet, super long, ocean long)

    • looks like a bar of metal maybe...kinda cool

  • note on using model coordinates

    • no 3D effect as we pan around the object (bad)
      • appears computations are fixed without regard to camera position
    • but it does make the coordinates local to the object (good)
    • solution: need to factor in model coordinates combined with the actual camera coordinates somehow...
    • that would give us our 3D effect

  • idea: try using model coordinates to calculate a point in space, but use EyeCoordinates to cast ray trace code?

    • result: it's starting to show depth, but it's also 'stuck' in certain viewing angles, which is odd

  • experiment last night tells me that eye coordinates are the appropriate ones to use, but need to instead use the values associated with the original model coordinates for the data to feed from...will have to mix this in somehow...but keep that in mind

  • try inversion of modelview_matrix on advancing vector point to produce original model coordinates

    • This was the solution, needed to revert eye coordinates back to model coordinates in order to calculate OG data points
      • needed to compute inverse of ModelView Matrix, and use it to multiply against the tracing eye coordinates, to then produce the OG model coordinates
    • if this works, also try it to make our bounds check using the original coordinates as well

  • next thing, getting the bounds check working

    • using fixed coordinates, and attempting to bounds check on reconverted model coordinates results in heavy screen flicker, but results look correct...not entirely sure why
      • try using it with vec4 from other applications, so we can keep our 'w'
        • no effect
        • attempting to determine what the 'black' is coming from
          • was coming from bad initial bounds detection, doing a safe initial check fixes it

  • increase max trace limit to 100

  • play with long sheet of clouds then

  • play with 2 different fbm colors being used, with diff seeds

  • read up on raycasting...seems to be a method to perform volume rendering (which is exactly what we want)

  • idea: using raycasting, allow us to compute from eye coordinates the approximate density of clouds being seen at a given fragment

  • sun does not reflect off of black...adjust that accordingly

    • just had to reinstate the alpha so the lighting doesn't reflect off of every surface

  • check if terrain displays under it

    • fix was ordering of elements since depth test was enabled
    • had to render opaque elements first (terrain, water, clouds, etc)
    • followed by transparent components (cloud volume)

  • calculate proper lighting for clouds now as well

    • compute 2 additional fbm points slightly off via x & z
      • normal doesn't look quite right

  • instead, try point lighting, calculate 2nd ray shooting from destination point to light, if it's clear light it, otherwise diminish by inverse of alpha encountered trying to exit the volume

    • this worked fairly well, 2nd ray to light source was used to adjust alpha of per-fragment lighting, as well as to be the normal for the lighting equation. result looks pretty good

  • lighting is a bit backwards from the light source to the actual clouds

    • small potatoes

  • what happens when the light is inside the clouds?

    • lighting looks good when the source is within the volume, all around drops off as density of clouds cuts off the light
    • still glows at the edges, softening them up a bit

  • improve water quality

    • step back to 1 solid color
    • add in vertex displacement via
      • better sin wave
      • and fpm
      • looks pretty decent with just lighting, and no color
    • now setup with color

  • water is far too shiny, reduce either:

    • the frequency of the wavelets
    • specular highlight factor
    • water looks much better now

  • finally, can the land be subtly improved texture wise?

    • yes, by increasing the sheet density (100+ looks okay, 200+ looks great, 400+ looks extremely good, but lags crazily)

  • improve water quality by using sharper noise (inverse of abs of sin/cos wave)

    • adds chop, looks good

  • clouds should be thinner, thick blocks are rare, adjust accordingly

    • add control var for cloud block height
      • bug with reducing height, produces empty block at the top of the screen for some reason?
      • ignored this
    • add control var for cloud density
      • somewhat okay

  • update help commands to include new commands for scaling cloud stuff

  • improve cloud performance, allow altering ray casting steps

    • something is slowing down cloud rendering like crazy (might be hash function?)
      • experiment with trying to improve performance by cutting off parts of the computation, and seeing how it performs after
      • playing around with single sheet
      • playing around decreased max (expensive anyways...grrr)
      • weird sheet artifact observed?
        • try setting default sheet color, remove discard, is it longer than we're seeing????
        • fixed, dimensions were bad
      • additional artifact observed when changing depth with a sheet of fixed size
        • seems to be related to initial position, change that a bit and see if I can find a spot with a small visual range
        • fixed, -0.2, 0.2...etc

  • add 'i' to ignore boundary checking in cloud volumes

    • doing this for 2D sheet to act a bit more like a window
    • looks good

  • is there an alternate random for glsl??? not a good one at least

    • there's an 'ok' one...maybe a topic to use a texture for later

  • can we use cool looking clouds with cloud sheet? I.e, 'fake' a volume by searching into the depth of the current one?

    • yeah, this works pretty well, especially without bound checking

  • add in source texture for randomness...

    • use last year's project
    • use that to sample for random points, rather than the extremely slow approach I'm using currently
    • keep the old way for reference
    • still just as slow, no discernable difference, even though the result was lackluster
      • sticking with hash for now, but there is definitely a way to improve the performance further

  • try playing around with bump mapping for terrain, not final, just curious

    • effect looks as expected, good facing directly down

  • consider reducing water effects to only be in fragment shader (unneeded to compute via vertex shader, except to adjust normal)

    • with respect to x & z still, so it doesn't get weird...
    • ehh maybe not, s & t will scale, and that could produce weird effects (maybe???)
    • no, try it out without reducing to the tile type first, then change the tile type after
      • seriously messed up the approach for waves, lost a lot of good definition, and shininess, so trashed this approach

  • land improvements that I was thinking of

    • none at the moment to apply

cloud lighting is off a bit, has to do with bad normals (had same problem with water but fixed it, y was wayyyy too far off)

  • normals still need some work

references