Jump to content

Azaezel

DEVGRU
  • Posts

    515
  • Joined

  • Last visited

Everything posted by Azaezel

  1. I'll simply say that I at least do not find further scattering of information a road to efficiency in any way shape or form, and ask: What additional data is lacking in https://github.com/GarageGames/Torque3D/milestones that you are looking for, exactly?
  2. Through torque itself no, though (except for Macs. Because Apple.) If there's an error, you should get console spew if for whatever reason a generated shader is non-compiling. If it's tacking the code-inserts on right, I'd look to the variable pass-along chain.
  3. Only working in debug sounds like somethings not getting initialized properly. Got a fork up to look it over?
  4. Did a little poking http://imgur.com/a/SddS8 kinda limited by the 512 demo restriction... What's your meters per pixel import wise?
  5. Were you expecting it to be a single value, and not 2 controls (reflectivity aka metalness and smoothness/roughness aka bluriness)? That's the only takeaway I'm getting from tossing up that line of balls and not a grid without some elaboration... Also for what it's worth, re-comparing AO at least did show a miscalc, which just got corrected.
  6. PR updated with script alts. *thiiiink* I caught em all, if someone would be so kind as to run a spot-check.
  7. Appreciate it. Been all over the place lately. Among other things.
  8. https://github.com/Azaezel/Torque3D/blob/afx_plus_3.8/Templates/Full_AFX/game/shaders/common/lighting/advanced/vectorLightP.hlsl#L70 Not offhand, but then, I've stuck to the regular full directory most times and thrown AFX bits in per-project... could be a script ref change... will poke as time allows... Which directory did you try as your baseline?
  9. https://github.com/faustlogic/Torque3D-plus-AFX/pull/1 make no promises other than it compiles. Does not function. Was removed in devhead. That's why that played up.
  10. Should note the main point of that particular model was the eydroppable grid http://i.imgur.com/F5o7Bx0.png as a quickie analogue for http://polycount.com/discussion/comment/2096031/#Comment_2096031 so if the wood is crap, by all means blame me for being a bad artist. if the *balls* look off, then yeah, that'll be a code flaw.
  11. Would https://github.com/GarageGames/Torque3D/pull/565 help, you think?
  12. Added a further demonstration/assistance model for artists that are unfamiliar with the system: http://i.imgur.com/3xf3yht.jpg http://i.imgur.com/t8SK6qg.jpg Smoothness is X, metalness is Y. Edit: forgot AO: http://i.imgur.com/m6gC7vf.jpg
  13. Honestly, what I'd do is hack into something like https://github.com/GarageGames/Torque3D/blob/2044b2691e1a29fa65d1bdd163f0d834995433ce/Engine/source/materials/processedShaderMaterial.cpp#L887 with https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7 The per-instance material damage in the vid was an older version that used that mMaterialDamage being passed around to modify the pre-existing detail feature alpha blend, for instance. So in your case... https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7#diff-ee63be9e1180cd38f5b10d798839b5f1R2604 would be something along the lines of rdata.setMaterialSpeed(getVelocity().len()); https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7#diff-8c164601ef835960f8dd7a4931f78792R161 for you setMaterialSpeed definitions https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7#diff-5507520a39aa2d8c9d489a38d0d85565R215 + https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7#diff-1edd3e647b9fb79d7c959cd66c077883R37 + https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7#diff-e344db6d2836ae639d06783f2388d090R175 for your glue code probably will need to alt https://github.com/GarageGames/Torque3D/blob/2044b2691e1a29fa65d1bdd163f0d834995433ce/Engine/source/materials/processedShaderMaterial.cpp#L783 to pass the sgData along so you can do the equivalent of https://github.com/Azaezel/Torque3D/commit/178703f19a601c3ca370514930ef6e39fa405ba7#diff-b7123dc2958b63669f99f0cd9ee534a5R1240 for your offset multiplier. (also probably want to add a flag to materials that conrols whether or not they're multiplied by velocity so you don't end up grinding the rest to a halt) Edit: further reading: http://wiki.torque3d.org/coder:extending-the-torque3d-material-system probably does a much better job of handling the whys.
  14. linearization turned over https://github.com/GarageGames/Torque3D/pull/1461 there will be conflicts once that's rolled in to head. will resolve those as the issue arises. also fixed the accumulation textures: http://imgur.com/a/K39yq in addition, working with timmy to roll in dx11 https://github.com/Azaezel/Torque3D/tree/PBRDX11 cleaned up findings will be backported to the main working branch.
  15. https://github.com/Azaezel/Torque3D/blob/2480e3cb954b87f9bca945acaccd788520f114f0/Engine/source/T3D/laser.cpp#L249-L250 https://github.com/Azaezel/Torque3D/blob/2480e3cb954b87f9bca945acaccd788520f114f0/Engine/source/T3D/laser.cpp#L305-L314
  16. Probably not. it was after all intended to be a bridge step for the entity component phase. Won't be removing it from hosting though if folks wanna snag it and tinker.
  17. It's a bit counterintuative but the left/right top/bottom bit refers to the space added or subtracted when resized.
  18. If you're building 64 bit aps, the O/S needs to be 64 bit. yes.
  19. For what it's worth, got a pop-in version https://github.com/Azaezel/Torque3D/tree/player_hitboxes_rev2 forget why I pulled the PR on that... something about aftermarket animation or node tweaks.
  20. Nah, just cranks a few values up like so: http://imgur.com/a/z0Dzw fars an animation goes... not stock. though I'll note there are bits and bobs of the material features laying around to turn a horizontal strip into a frame by frame flipbook as it were.
  21. Kinda stalled out on the query thing, so took a breather and started comparing deferred to the upcomming dx11 work. One of the nastier conflict-points was the linearization step, so rewrote that for clarity. Now defines a toLinear and toGamma method that runs after texture loading for diffuses/albedos, instead of taking it's place in shadergen (and water). Also cooked up a substance converter for the solider (still wip, but should give folks ideas), and cleaned up that fouled stone material. (Also rolled in the two submitted forks from the above thread)
  22. Threw a different hardware spec at it from one of the mac users in my own crew, and she played up until we killed off https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/core/scripts/client/lighting/advanced/shaders.cs#L46-L52 so the focus-point will likely be around https://github.com/GarageGames/Torque3D/blob/2044b2691e1a29fa65d1bdd163f0d834995433ce/Engine/source/gfx/gl/gfxGLStateBlock.cpp#L142-L149 or so.
  23. To be a bit clearer there, we've isolated it down to a non-default setting https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/core/scripts/client/lighting/advanced/shaders.cs#L27-L52 being misinterpreted. still need to track it a bit more for a proper fix. Also need to hunt down terrain detail blending going a bit pearshaped looks like. (which may very well be stateblock based as well, for that matter.)
  24. edited the above. had the wrong link for hutch's specular/lightcolor/specularmap test (the first two reference lightinfo, the third, the upcomming tertiary rendertarget, matinfo. apologies for the confusion.)
×
×
  • Create New...