Jump to content

Azaezel

DEVGRU
 View Profile  See their activity

  • Posts

    515

  • Joined

  • Last visited

 Content Type 

Posts posted by Azaezel

    PBR: Principles, Practice, and Prepwork

    in Rendering

    Posted

    (Normal with heightmap data would be a nice addition to T3D :) )

    It's there stock. Parallax slider + alpha of the normalmap. If it wasn't, I wouldn't be so concerned with trying to circle back and fix it, since folks wouldn't miss what they don't have nearly as much.


    That being said, to cut down on things to wade through specifically related to PBR (and to fullfill at least par of the whole 'and prepwork' portion of the thread tag), http://forums.torque3d.org/viewtopic.php?f=9&t=387 will be one of the first subsystem extracts tossed over as soon as The Last Bug Dies.

    Shadow Caching status

    in Rendering

    Posted

    https://github.com/Azaezel/Torque3D/tree/shadow_cache

    Additional Contributors: @andrewmac, @LuisAntonRebollo

    Target: 3.9

    • Deferred Shading
    • Shadow Caching

     

    So. those of you that have been following along with the Deferred or PBR branches have likely gotten a bit of a taste of this already, but in the interests of letting folks digest things in a nice testable manner, the first thing out of the gate will be the shadow caching subsystem.


    Anyone familiar with pretty much any engine knows that shadows are one of, if not the most hefty hits on the rendering pipelline. Dynamic more so than any other. Stock torque to date uses fully dynamic shadow regeneration per frame for everything unless you explicitly bake them in a third party application via lightmapping tricks, additional materials, et al.


    To alleviate this a bit, Andrew and I dug around a bit and dug into regeneration portion of the shadow gen subsystem, augmenting it with a pair of cyclic updaters.

    Here's how this works:

    Materials gain a new flag: http://i.imgur.com/Qld0ioR.jpg

    Lights gain 2 new millisecond entries: http://i.imgur.com/iKZby4B.jpg


    Lights start out as now, generating shadows across the board. but no longer update every frame. Instead they wait until either the dynamicRefreshFreq has expired if it's tagged as dynamic, or the static one does if it's static to redraw the relevant portions of the 'shadow scene' for lack of a better term. At time of writing, all materials default to dynamic by request in order to least disturb existing projects, which means folks wanting to take the most advantage of that will need to flip that off for all background materials. (those wishing to automate the process the other way around juts need to flip https://github.com/Azaezel/Torque3D/commit/cff46be3c4eb15bf3f779dfe69589f5716b54cbc#diff-3d0e4d9e155d0616540a32291c591c75R185 and tag players or anything animated to true.


    Now the bad news: Turns out there was a lurking bug in https://github.com/Azaezel/Torque3D/commit/48f3ae1e6c873906dcb957c4bc79b4466c4eae99 causing severe issues with spotlights in particular, though given the formation, that was more of a timebomb waiting for someone else to step on it at some point anyway, so looking to fully address that.


    At present, that brings the bug down to one report, specifically in debug mode, of

    OPENGL: GL_INVALID_OPERATION error generated. Cannot begin query on an active query object.

    per light after which queries operate correctly rather than continuous spam from both that one and a secondary error report. (http://i.imgur.com/EdOdT2z.png)


    Additional research notes on that matter:

    https://www.opengl.org/sdk/docs/man3/xhtml/glBeginQuery.xml

    GL_INVALID_OPERATION is generated if glBeginQuery is executed while a query object of the same target is already active.


    As this stuff was always intended to be a community project, if folks want, I can flip that over to PR (after cleaning it down to the one documented commit) and let someone clean it up in the development fork, but my first instinct is to hold off on that until this last bit is sorted fully.

    Mac-Heads, Unite!

    in Looking for help

    Posted

    so. Status update for the week:

    short version: no visible resolution, though we found a few interesting bits.


    Long version with many links for folks to poke along:

    We threw deferred at it, since among other things, that had additional visualizers and namedrendertarget references. results:

    http://imgur.com/a/gsDYG - windows/linux

    http://imgur.com/hJJ6w2z + http://imgur.com/a/hBOP8 Hutch's Mac.

    from that we can tell that https://github.com/Azaezel/Torque3D/blob/mac_deferred/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L79 is getting read right, but https://github.com/Azaezel/Torque3D/blob/mac_deferred/Templates/Full/game/core/scripts/client/lighting/advanced/lightViz.cs#L162 is not, while

    killing off all but a red-return for https://github.com/GarageGames/Torque3D/blob/development/Templates/Empty/game/shaders/common/lighting/advanced/gl/vectorLightP.glsl returned a red-tint light for win/linux and remained black for mac, which pretty much re-confirms that it is in fact a lightinfo buffer, and lighinfo alone I/O flaw.


    We did find two additional points of strange behavior directly linked to the GFX subsystem, https://github.com/GarageGames/Torque3D/pull/1428 and https://github.com/JeffProgrammer/Torque3D/commit/c04125f4e6bda47b95fa7e516cce26639da79c83 (the latter was spitting out insanely high divisors into the shaders/proceedural/autogenconditioners.h file rather than the expected 65535.0)


    Additional points that caused raised eyebrows:

    https://github.com/JeffProgrammer/Torque3D/blob/macosx/Engine/source/gui/3d/guiTSControl.cpp#L516


    https://github.com/JeffProgrammer/Torque3D/blob/macosx/Engine/source/app/mainLoop.cpp#L576


    https://github.com/GarageGames/Torque3D/blob/b1d2ba8412bf2dc5688ae563dea416bc9407f4fd/Engine/source/ts/tsMesh.cpp#L246 (shouldn't effect terrain though)


    https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/gfx/gl/gfxGLAppleFence.cpp#L35 VS https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/gfx/gfxFence.cpp#L42-L68 (several potential things missing there, like stateblock, event delegate, and RTT)


    We also threw out the lions share of gglHasExtension as having causality by stripping those off the win machine to see if that could cause replication. It didn't.


    Sadly, the partridge in a pear tree did not magically show up at the last second of the week to edify us on what else we could be overlooking, so if anyone with additional insight would like to weigh in, it would be greatly appreciated.

    Torque 3D 3.8 Released

    in Torque 3D Announcements

    Posted

    What's shadergen? A built-in tool to create materials for T3D?


    Thanks a lot for the hard work guys!

    It's what translates those material entries like https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/art/shapes/actors/Soldier/materials.cs#L23-L39 into shader file snippets (think a node system, but a bit more hardcoded in terms of what order the logic is inserted, and the like) and combines them into procedural shaders that directx or opengl can actually understand.

    PBR: Principles, Practice, and Prepwork

    in Rendering

    Posted

    translation: 

    If we've added the deferred flag-feature (we're using what was the prepass class)
output color to the second (color) buffer for recombination later
else
output color to the standard buffer

    put that back to stock for a bit to see if that'd mitigate the normal-with-hieghtmap-data blending problem mentioned upthread. will have to cook up a better solution, clearly.

    Mac-Heads, Unite!

    in Looking for help

    Posted

    To elaborate on the testing done as of tonight, some additional notes, which may or may not all be related:


    Outpost on hutch's machine:

    Reflection, particles, precipitation, scattersky, cloudlayer, and the tree imposters for the forest - proper coloration

    All visualizers save for the new one running through vectorLightP.glsl to display PSSM_DEBUG_RENDER information render properly. (so normal, depth et-al are getting packed right)


    Prior testing via empty terrain:

    any translucent, or emissive/glowing object, multiple layer materials, scrolling et-al all operate properly.

    Material preview window render offset. (Possibly flipped vertically?)


    --Nontranslucent objects render black, though thier profiles appear to be correct.

    --No smearing from the buffer not being cleared properly.

    -- No shader compilation errors or warnings. Forcing https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/shaders/common/lighting/advanced/gl/vectorLightP.glsl into a non-compiling state did report errors.


    --Recieving warning spam of the form:

    Program shadergen:/f1d4dbcc_V.glsl / shadergen:/f1d4dbcc_P.glsl: WARNING: Could not find vertex shader attribute 'vTexCoord4' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord9' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord2' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord7' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vBinormal' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord5' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord8' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord1' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord3' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vTexCoord6' to match BindAttributeLocation request.
WARNING: Could not find vertex shader attribute 'vColor' to match BindAttributeLocation request.
WARNING: Could not find fragment shader output 'OUT_col3' to match FragDataBinding request.
WARNING: Could not find fragment shader output 'OUT_col1' to match FragDataBinding request.
WARNING: Could not find fragment shader output 'OUT_col2' to match FragDataBinding request.

    Lightmapping in Torque3D

    in Rendering

    Posted

    For what it's worth, I'll simply note two things in case someone with the time wants to hop on the notion:

    1) Those .ml files spit out by basic lighting represent an extremely old version of lightmapping, so that might be a point to drill into.

    2) Head already supports lightmapping usage, (UV2) just not generation. (As does PBR. so not an either/or situation.)

    Sahara/Material Accumulation

    in Beginner

    Posted

    http://i.imgur.com/aKZIWBj.png


    The submitted conversion uses accumulation volumes for mapping textures to objects in areas. You'll find that under library->level->level : http://i.imgur.com/V0ijUsU.png


    Do note two things at time of writing:

    A) You'll need a normal map.

    B) Looks like a bug slipped by that requires a level reload to trigger tying materials that were not already prepped to receive accumulation layers together with the inputs. Still tracking the particulars there.

    Grass issue

    in Rendering

    Posted

    There's a couple options there, actually. Blend into terriain is usually https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/art/environment/materials.cs#L5-L8 and best done with grass that only pops up on similar colored terrain.


    https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/art/environment/materials.cs#L15-L18 is a straight discard, with no attempts made at blending, just shows or not, so for that, you'd have your grass set up with a sharp alphamask to avoid a 'stippling effect' as it were.

    Torque 3D 3.8 Release Candidate

    in Torque 3D Announcements

    Posted

    @timmy: and the _P? looks like that ones a vertex shader, and most of the time temp variables crop up in pixel shader loops.


    On the sdl2 keybinding front... still looking into it https://github.com/Azaezel/Torque3D/commits/SDL_Synergy (Code-dump courtesy of mango: https://onedrive.live.com/redir?resid=5FBC82584B785711!1683&authkey=!AOFSAyCieMxPn54&ithint=file%2czip , though a straight drop-in and replace still showed some interference. Might rule a few things out though.), don't think that's gonna make cutoff however, unfortunately.

    am i violating any law?

    in General

    Posted

    Nope. MIT licence means you can do what you want with the thing as long as you keep the initial blurb in. Up to and including adding your own restrictions on access.


    Edit: Case in point, it'd certainly be *nice*, and definitely encouraged if you threw back any fixes for flaws you run across, but strictly legally speaking, you aren't *required* to do so. Just slows down getting yet more goodies since folks have to independently find and fix em themselves instead of looking into other things.

×
×
  • Create New...