Jump to content
The Dark Mod Forums

nbohr1more

Development Role
  • Posts

    12146
  • Joined

  • Last visited

  • Days Won

    200

Posts posted by nbohr1more

  1. One last silly conjecture... (please feel free to let the crickets chirp on this one...)

     

    Since we cannot acquire position data from the engine to tell the Instances where to go, we could encode vertexes with markers (like bump patterns... braille?) that would make finding them in the Vertex Buffer easier. Now this craziness depends on how reliable the Vertex Buffer Object is (which has been an area of frustration for game developer for awhile AFAIK...).

     

    So the algorithm would be:

     

    1) Create a terrain mesh

    2) Encode vertex bumps that can be decoded for relative positional data into the mesh

    3) Create a "texture" that is really just a lookup table for the codes

    4) Create a texture that is encoded with a tree mesh (or extreme normal map... but the math would be, uh... complex..?)

    5) Create a "Particle Effect" shader that covers a certain radius around each "bump marker"

    6) When the Particle Effect is invoked it will snoop the Vertex Buffer for these bump markers

    7) Once 3 markers are found, the remaining relative positions in the mesh data can be decoded from the "lookup table texture"

    8) Use the mesh texture with VTF or R2VB to modify one (or all) of the marked areas in the Vertex Buffer

    (even without instancing we have succeeded in creating new geometry on the GPU without pulling out a credit card and calling up John Carmack)

     

     

    (optional steps, presuming we only created one tree above...)

     

    9) Either generate position data codes from the original snoop data via mathematical offsets or snoop all the encoded items for positional data nearby.

    10) Use step 9 for the position stream for Geometry Instancing

     

    Each cluster of trees would radiate from a group of 3 markers found in the Vertex Buffer.

     

    Caveats:

     

    1) You would need to somehow ensure that the dmap process would not modify the geometry in the encoded areas

     

    2) If the data in the Vertex Buffer is as unreliable as has been mentioned in the past, we would probably see artifacts like trees flickering in and out of existence...

     

    I'm sure if someone tried this we'd get zilch but it's my compulsion to have my suspicions confirmed by outside eyes (again, let the crickets chirp on this... it's just my OCD)...

  2. Dont mind me I just like having more FMS to try out :laugh: :laugh: :laugh:

     

    When I was in high-school I gained a certain amount of mastery at drawing. At some point after that I began to run out of creative juice. I often found that if someone scribbled something and asked me to "improve it" this spark would give me ideas to continue on and create cool stuff. I ran into the same thing when I became a musician in college, I often needed some riff or motif to start the process.

     

    I suspect that Fidcal might work the same way in some respects...

     

    If so, hand in your scribbles folks! :laugh:

     

    (Not that I'm calling Sotha's work a scribble... this is why I'm introverted... foot-in-mouth syndrome... :wacko: )

  3. Ooops, I missed that info! However, "SHAPEOBJECT", "LIGHTOBJECT" or "CAMERAOBJECT" do not appear in any files.

     

    There are a few with "GROUP" in them, can you please test that they work?

     

    models/darkmod/misc/target.ase
    837:*GROUP "Group02" {
    838: *GROUP "Group01" {
    
    models/darkmod/tools/saw_2man_long.ase
    123:*GROUP "saw_long" {
    
    models/darkmod/tools/saw_hand.ase
    159:*GROUP "handsaw" {
    
    models/darkmod/architecture/windows/windowframe_wood_40x36.ase
    87:*GROUP "windowframe_40x36" {
    
    models/darkmod/architecture/windows/windowframe_wood_80x72_glass.ase
    123:*GROUP "windowframe_80x72" {
    
    models/darkmod/architecture/windows/windowframe_wood_80x72.ase
    87:*GROUP "windowframe_80x72" {
    

     

    (except the "target.ase" on, as you version still contains HELPEROBJECT so it will complain, anway.)

     

    Edit: Tried the two saws and a window frame locally here, and they work ok, so apparently "GROUP" is okay. Unless you report otherwise, the bug is resolved then :)

     

     

    No errors in NHAT 3/3 conDump ... I'd say the fix is confirmed

  4. I believe this is your choice:

     

    1) Make one big func_static to reduce draw calls but hope that it doesn't have too much geometry

     

    or

     

    2) Have lots of sub-components, like the columns, which either will or wont be rendered depending on the visportal but hope that the number of draw calls to invoke these elements doesn't choke the engine

     

    The decision comes down to the size and complexity of the map or map portion. I imagine that someone with more time than myself has actually worked out the best ratio of func_static complexity to draw-calls for a select range of CPU models. :laugh:

     

    (as I've often said, I mostly post before thinking so take all this as a bunch of lazy guesswork)

  5. I thought you would chime in... :laugh:

     

    I also figured you would've tried all the conventional or advised options...

     

    The forest idea has always been of interest to me (from a real-time 3d POV) because it's such a challenge.

     

    The problem is actually well suited to things like Tessellation, GS, and other advanced geometry tricks. Too bad that these cant currently be used...

     

    Out of curiosity:

     

    1) Was this map created this way to be a Balls-to-the-Walls extreme test of the engine and modern hardware?

    2) What was the slowest CPU that this was tested on?

    3) Was this map tested on any AGP systems (I have a terrible feeling that a lot of CPU communication to the GPU is happening here)?

     

    Thanks.

     

    (actually I'm not sure if the first question should be directed at you or GC )

  6. Did any of you TDM fans who watched this film instantly become jealous of the render quality of the torches in this film? :laugh:

     

    Just so I loose my last shred esteem...

     

    I actually thought that this was a decent return to form from the last two films.

     

    There was an actual story.

     

    And Eddie Murphy's riffing on his "donkey as metaphor for underpaid minority" was actually pretty sharp and funny compared to the empty pop-culture references of 2 and 3.

×
×
  • Create New...