Azaezel

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.

https://github.com/Azaezel/Torque3D/tree/shadow_cache Additional Contributors: @andrewmac, @LuisAntonRebollo Target: 3.9 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.

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.

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.

Don't have a DX11 fork up as of yet. I'll leave it to the various authors poking at it themselves to say more on that score.

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.

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.

Oddball. And you're entirely sure https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/environment/waterObject.cpp#L343 is the determinant your end?

https://github.com/Azaezel/Torque3D/commit/902696e75403b6e72556937a9f98cac4cc9e950e go ahead and slap that in when you've a chance. Should push the reflected scene generation back to object creation instead of when-first-in-view, which is what that useOcclusionQuery does. (IE: it's testing if the *reflective object* is no longer occluded prior to ramping up.)

Extremely. But that is apparently what http://www.garagegames.com/products/purelight plugs into, so a bit hesitant to do much beyond ensuring that the sample @Steve_Yorkshire was kind enough to throw my way to make sure that end didn't break, what with all the other little things on the present personal plate.

https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/materials/materialDefinition.cpp#L228 for the material entry https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/T3D/levelInfo.cpp#L157 for flipping on the render target it draws to then blends in. (off by default in head)

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.)

With or without HDR, or is that relevant your end? Why I ask: https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/scene/reflectionManager.cpp#L86 https://github.com/GarageGames/Torque3D/blob/6b9e5dd15e67b152500a3ed0e3e58c695d2c959d/Engine/source/scene/reflector.cpp#L541-L547

Probably my fault. Try: https://github.com/Azaezel/Torque3D/commit/8f0eafc3a3ae0f68a150fa3255a3625c418422a8

Yeah, it's an either-or switch. Either use the % stored in the R and B channels per-pixel, or look em up for the whole material. Haven't really gotten around to genning more non-personal-game ones as of yet, unfortunately, no.

Yes. Same as it would be pointless to have pixspecular and those sliders on if you were feeding it a spec map in head.

Followup to this one: http://forums.torque3d.org/viewtopic.php?f=12&p=3108#p3108 Stock flaw, though there is still a bit of overly bright discoloration due to the not-quite-completed conversion there: http://i.imgur.com/H2xzpzp.png

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.

Mind circling the bit that is unexpected?

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.

I... don't have a proper response to that... Hardware Specs?

If it is, about the only thing that sticks out that'd likely be applying too much pressure might be https://github.com/Azaezel/Torque3D/commit/15f477a451447805b81adf0e7dcf0745b4a504fe if yall want to try and throw that at it, see if that helps or not...

@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.

Tough to tell without a vid, but tried the other one: https://github.com/GarageGames/Torque3D/blob/c152ae86f3f09b3c1d736954b352723d274582f1/Engine/source/scene/sceneObject.h#L469-L475 ?

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.