Jump to content

TorqueFan

Members
  • Posts

    130
  • Joined

  • Last visited

Everything posted by TorqueFan

  1. TorqueFan

    Toon shading

    Ah, nevermind. The one-line change is still relevant - I just didn't search well enough for it the last time! :oops:
  2. Ah sweet, nice to see others still have interest in the future of the GuiObjectView class! I applied the proposed frustum fix, thanks for the head's up. Still unable to render a transparent background, though at least the fog data fix makes it usable. Basically end up with a semi-transparent light grey background, so worst case scenario I just am forced to layer a darker layer behind it. Much more restrictive than complete transparency, but at least workable ;) Most importantly, it appears it will be in a solid enough state to polish up and share as a resource with that bright 'fog-tri' fixed. No ETA just yet on that, as I'll need to carve out the time to type out a proper explanation of all the updates. :geek:
  3. Was just about to dig into that GuiTSControl when I realized the 3.8(DX9) version of GuiTSControl was nearly identical to the 3.9(DX11) one. The 3.8 GuiTSControl works under DX9 (no background quad thing), so that's a no-go. Unfortunately, the issue is much more deeply rooted in the DX11 rendering code(it would seem). I thought I might be able to prevent the GuiObjectView from becoming deprecated, but it appears I am the only interested party. @Azaezel: If nothing else, could you pass along the information to those mighty tinkerers of the DX11 code? Basically after 3.8 the GuiObjectView can't be rendered without the background quad problem, which effectively makes the class unusable under DX11. It's a shame, I have extended the class A LOT and even built character creation GUI's all around it. Months of development that will forever be stuck in 3.8 and DX9 without the GuiObjectView being correctly fixed for DX11. EDIT: Further testing is required, but your insight on 'fog' might have just paid off...I was perusing this thread and included your example "restore fog setting" in my GuiObjectView's render code. Again, more to test, but atm it appears this fog gClientSceneGraph's fog data might have been the culprit all along - (At least for GuiObjectViews blended with the PlayGui, still seeing the bg quad problem in GuiObjectViews rendered prior to PlayGui). EDIT 2: Okay, the fog data was causing GuiObjectViews blended with the PlayGui to show a bright tri in the background. The relevant sections on gClientSceneGraph's fogData in the GuiObjectView's renderWorld() code posted on page 2 of this thread will fix that problem. This makes the class at least usable over PlayGui!! However, the background of the GuiObjectView can still not be made transparent in any case.
  4. @Azaezel - I noticed that the GuiTSCtrl from which the GuiObjectView is derived has undergone quite a few significant changes for DX11. I am going to explore the option of creating another entirely new class based off of GuiTSCtrl from which to derive my updated GuiObjectView. This way we don't have all of the necessary GuiTSCtrl rendering stuff(which is used by the actual PlayGui) bumping heads with the needs of the GuiObjectView's rendering code. Wish me luck!
  5. TorqueFan

    Toon shading

    Anyone get this working in any of the newer T3D builds under DX11? The shader code is a bit different now.
  6. As promised, I am appreciative of your insights Az ;)
  7. Hey this is great news! Thanks so much for all of this effort, to all involved. Open source power at its finest - revealing the true strength of Torque! I am so ready to convert all my resources and tools over to module form! Is that a realistic goal for this release, or is the module system not complete in this build? I've been twiddling my thumbs for a bit dealing with other company matters while this whole 3.9->4.0 update blows over...but if the module system is ready for my tinkering I could start pumping out some tools/resources! Speaking of the new modules etc., is there a 'guide' or explanation someplace on how to use all this new shiny stuff? Like templates to follow, tutorials on new module creation and so on?
  8. @Azaezel Any chance you've had any look at 'da list' lately Az? Particularly the "background quad brightening crap"? With the forward momentum around T3D 3.9 ->4.0, I've taken an interest in updating all of my resources into module form. Still a fly in the ointment, though, as I hadn't figured out what is going on with the postfx/stateblock on the GuiObjectView class. If you get a chance to take a look or make any suggestions I'd sure be appreciative. It's been a thorn in the side for some time now, and I'd love to complete this work on the class so it can be shared with the community!
  9. @Timmy ...research complete! Thank you so much, I do enjoy a good read! You, sir, are a gentleman and a scholar. That all makes sense, and I'll be adjusting some of my detail maps accordingly to suit. ;) By the way I did run into one other small issue with the GuiObjectView port, where the background isn't transparent. I believe @Azaezel has a better understanding of the source of the issue. In this post, he gives mention to some changes to the class that may be necessary to make a 'complete' conversion of GuiObjectView from the old to the new. Some may not be necessary, per say, but as the goal is always to innovate and improve I believe all of his proposed updates could benefit the class.
  10. @Azaezel Okay you have given me a LOT to take in in the span of a single posting. I was wondering what had changed that was making me have to set the 'usePostFx' to true during renderWorld() calls using the D3D11 build( or have the model not display at all ). The problem is, though, when using the postfx( which is a must-have now ) the GuiObjectView's background is not transparent. Is this the "background quad brightening crap" of which you speak Az? @rlranft The things that Az are looking into will seal the deal I believe moving forward for 3.9 and beyond. I'd like to ensure that we can solve this 'background quad' issue ( or whatever's causing the background of the view to not be transparent ) before posting up the GuiObjectView resource. Those features I've described I have working in 3.8 and the latest 3.9 development branch( other than the background not being transparent for D3D11, but that's not as a consequence to any changes I've made ).
  11. Yea I can see where some improvements could go a long way in some areas. Thanks for the information about a potential WIP around the GuiObjectView's rendering code. I'd be interested to see what changes @Azaezel makes to the class! Hopefully he'll chime in and let me know =)
  12. I use GuiObjectView rather extensively in my current project. Recently I've extended the GuiObjectView class with 4 new features that make it much more usable: Added sub mesh support : To show and hide sub-meshes within a parent mesh( source code and console commands ). Added sub mesh skinning : To change skins individually per sub-mesh within a parent mesh( source code and console commands ). Added node support : To toggle on/off use of nodes on the mesh. If in use, camera can be set to node locations( source code and console commands ). Added blend support : To use blend animations with the displayed mesh. Supports blending animations with root animation pose( source and console commands ). Are there other features that you'd like to see @rlranft ? When I get time to clean up my code and revisit this I plan on sharing this improved GuiObjectView class with our community, so please do let me know if there are improvements that might be able to be made. :D
  13. Oh nice, thanks for looking into that. If not later this evening than on tomorrow I should be able to confirm. @Timmy, could you help me to understand the 'normal' workflow used when importing detail textures now? Like prior to this, I'd either use a high pass filter or something very similar when creating a detail map for T3D. What do you describe as "appropriate" textures and how do I import my texture properly? EDIT : Confirmed the updates, thanks a lot. :D If not detail maps, surely something would have come up. All material definitions working great now!
  14. Awesome, yep, drawRect() offset fix works great thanks! GroundCover Okay, here's what I found about GroundCover object. The problem I ran into deals with the material definition. In my case, I was adding a detailMap layer to the material. This was giving me a little more creative freedoms on how the material would ultimately look - BUT that was pre-D3D11. I've already noticed that some of my other materials that use detailMap layers look different than before this merge...but in a good way. So I need to update my art across the board a tad to fit D3D11( that's a good thing ). Here's the problem: singleton Material(Mat_Grass) { mapTo = "Grass_cover"; ... detailScale[0] = "1 1"; detailMap[0] = "art/environment/cover/Grass/Grass_d.png"; }; If I comment out the detailMap and detailScale here, there is no problem at all. If I don't comment that out, I get an error popup about 'can't compile shader'( same error as in the log I posted before ). Now, I dug a little bit deeper around material definitions because D3D11 in Torque is too much win! I created a new GroundCover object( D3D11 build, Empty Terrain mission ) and then for the material I set it to the Lurker rifle's muzzle flash. Boom, same error as above. Now obviously the muzzle flash sequence was never meant to be a ground cover material, but a user could potentially want some other sort of animated ground cover material. I followed this procedure for several materials - some would work and others would not. Ultimately I found that these variables did work fine in material definitions in any case : mapTo = diffuseMap[0] = diffuseColor[0] = doubleSided = translucentBlendOp = alphaTest = alphaRef = materialTag0 = normalMap[0] = specular[0] = specularPower[0] = glow[0] = emissive[0] = useAnisotropic[0] = castShadows = castDynamicShadows = These caused the crash : detailMap[0] animFlags[0] = scrollDir[0] = rotSpeed[0] = rotPivotOffset[0] = waveFreq[0] = waveAmp[0] = I'm not sure which of the animation variables caused the problem, I just included all that were used in the muzzle flash sequence I tested. Cheers!
  15. Okay, pretty much the whole project is ported now. GuiObjectView Fixed I Fixed the GuiObjectView problem and found the culprit in a couple checks I added. I'm not entirely sure what changed behind the scenes to break it in the first place, but here are the details: I use an enum to initialize a name index, like this: enum blendAnimations{ eyeScale0 = 0, eyeScale1 = 1, eyeScale2 = 2, eyeScale3 = 3, eyeScale4 = 4, totalBlendAnimations = 5 }; String mBlendSeqName[totalBlendAnimations]; The problem was I was calling... if (!mBlendSeqName[mChosenEyeScale].isEmpty()) ...where mChosenEyeScale is just the index value chosen through the GUI's. Oddly enough, these checks worked fine prior to the D3D11 merge. I Removed the checks, which to be completely honest seemed a tad redundant anyhow, and wham all is well. Using the example above, adjusting eye scale with a GUI slider is possible via blends! /shrug - But hey, who cares?! I managed to fix my own problem, port the entire project over to D3D11, give a chunk of feedback, and spot a couple (potential) bugs. I extended the GuiObjectView with 4 new features, so look forward to that being up on GH soonish. When I get the time again to revisit this I will try to port over some custom sky rendering classes I've pieced together along the way to see how they go. Hey, thanks again for all the work on this!!
  16. Quick Update( The good so far ) : Terrain materials all work great. Diffuse, Normal, Specular tested. Even works when the terrain is generated and layers applied during runtime...D3D11OK Dynamically building a player object with sub-meshes works great...D3D11OK Passing tab-delimited strings for multiple materials on an object( or terrain )works great...D3D11OK Custom materials on CloudLayer works great...D3D11OK GroundCover with shapes ONLY works...D3D11 partially OK ( The bad so far ) : Same offset rectangle bug appeared when I used the 'metrics(fps)' console command. The rendered white rectangle in the fps display is offset and not contained within its border properly. ***CRASH *** GroundCover crashes the application for me when I try to load or add groundcover textures. I'm not extremely savvy with shaders, but it should be easy enough to track down. Here's the log: failed to compile shader: C:\dev\DX11\Torque3D-development\My Projects\Test\game\shaders\procedural\5d52451f_V.hlsl(64,4): error X3017: 'foliageProcessVert': cannot implicitly convert from 'float2' to 'float4' Still porting... :arrow: Update: DragControls across separate GUI's works great...D3D11OK Player mounting weapons works great, even with dynamic lights or particles attached...D3D11OK Update 2: GuiObjectView custom skinning complete...D3D11OK That's all for tonight! 2 of the 4 features are re-enabled now for the GuiObjectView, so before I run into the actual culprit problem I'm going to get some rest!
  17. @Timmy I have ported over probably 3/4 of the project now, and hope to finish by tonight or tomorrow. :geek: Along the way, I have been pleasantly surprised to find many things working great. I know some of this isn't directly related to the D3D11 PR, but figured I'd list it all here for completeness. Here's a recap, I did find one tiny issue so far: Tested OK with D3D11 : All imported models work flawlessly. This includes multiple materials, animations, blends, you name it...D3D11 OK All imported custom GUI's work flawlessly(20-ish + GUIs). This includes fading GUI's and so on that use custom rendering code...D3D11 OK (more on GuiObjectView below) Entire rework of scripts dealing with customizing, connecting, and launching a new mission all work flawlessly...D3D11 OK All custom terrainGen source and scripts generating flawlessly...D3D11 OK (still hooking in terrain materials this evening but the terrainGen is good) Custom .mis files including many of T3D's existing classes work flawlessly...D3D11 OK Still to Test with D3D11: Full implementation of extended GuiObjectView class...PENDING Finish hooking in materials for terrain, groundcover, etc...DONE DragControls in drag/drop interface...DONE One Small Issue with D3D11 found so far: Added a guiProgressCtrl to a GUI and when I set the value up so the progress bar would show some progress - the progress rectangle wasn't rendered perfectly within the border of the control's extents. Not sure if anything dealing with calls to drawRect() or similar were altered but I figured I'd bring that up. About extending GuiObjectView class: Basically prior to D3D11 I had 4 features added to the GuiObjectView class so I am currently just plugging them all back in one by one. The good news is my GUI's using GuiObjectView all still work, albeit with far less features. I did get the sub-mesh support plugged in and working again today, so one can hide/show sub-meshes on the model in view using script. Just 3 more features to go... :D
  18. I'll keep that in mind, although the project was sync'd with 3.8 development prior to this coming up. There are a lot of moving parts on my end that tie into this, though, so I just have to do the work. This update is significant enough that I am keeping a build sync'd with its changes. After I pop the hood and iron out my issue I'll let you know about what went wrong for me. Thanks again for all your efforts, and to all contributors!
  19. I just took a look into it, and very quickly realized that the source of the issues was from my own merged code! My custom GuiObjectView code extends the class to support cam nodes, blend animations, and hiding/showing sub-meshes. It all works fine pre this D3D11 merge. But there's a catch, of course : All of this stuff is hooked to new GUI's and supporting scripts for said GUI's. So it's a tad bit of work but I'd be willing to wager I'll find the culprit hiding someplace in the initialization functions for the class - either in script or source(i.e. onAdd() or initMaterials() etc.). Bottom line, though, is I am able to use the provided D3D11 branch without issue prior to merging my updates. Therein lies the quandary - now I just have to buckle down and fix it lol. I don't believe a log will be necessary but at some point I did want to release the extended GuiObjectView code as a resource to the community. I'd definitely want my changes to be compatible with the D3D11 update =) I'll have all the changes available on a GH branch soon enough(cleaned up a bit), so if the problem persists maybe someone could identify it. Moving forward I plan on blogging and sharing about my experiences with T3D, while providing code resources and so on. It's a geeky need that simply must be fulfilled - but more on that later (soon™). Anyhow just wanted to be sure I let you know asap about my findings. The last thing I'd want is to have you chasing ghosts :shock:
  20. @Timmy I should have time to look at this closer by tomorrow. Chances are if it's working okay on your end it's a project specific problem on my end. I'll discover what changes I've made that are conflicting with the dx11 branch :D
  21. Honestly my repos are a mess. I had a couple tiny PR's ready to go, but lost them when I was updating my dev branch :( Luckily they were tiny little fixes, but I'm not entirely keen on updating a dev branch in GitHub without damaging branches I've made from it. Perhaps I could just put those changes in the forum as a resource? The first change is literally a one line change, and it's subtractive at that( comments out an existing line of code ). D3D11 I was able to get it to compile using VS2013 on Windows10 without issue. Select DX11 and use it from options menu no problems with GTX 980. I found 2 problems right away with my main project that prevented further testing with that project: ° CRASH - When opening GuiObjectView the application would crash. I assume it's when loading the shape or animation from the shape. ° BUG - Objects don't appear to support multiple materials. All my models would render with one material and the other materials on the model rendered white. When I get a bit more free time I have some side projects with project-specific rendering code I will test with this.
  22. @Timmy Thanks so much for this effort. This is the expansion to T3D's API I have been waiting for. It feels really good to see this sort of initiative from the community. Recently I've pulled my head out the sand and decided to dust off my GitHub repository. I'm finding lately that many of the source changes I've been doing could be useful to others sitting in a repository. I've even got a couple super simple pull requests I really should run by the committee. When I see this sort of initiative from my peers, it really gets me motivated to use a little free time to contribute a bit back myself. Thanks for that, Timmy =) Anyways, I guess I just wanted to express some sort of gratitude for this work and let you know I'll be testing it fairly thoroughly soon(potentially with a few different game builds).
  23. I had a free moment and took a glance at it. I hadn't tested anything, but can lead you in the right direction. The original resource you posted just changed a single function to use an overload. I found that same function, just shifted around to a new location. ° shapeBase.cpp - around Ln. 2625 void ShapeBase::renderMountedImage( U32 imageSlot, TSRenderState &rstate, SceneRenderState *state ) { ... getRenderImageTransform(imageSlot, &mat, rstate.getSceneState()->isShadowPass()); ... } So you should be able to just change that line to: getRenderImageTransform(imageSlot,imageData->muzzleNode,&posMat); Basically the registerLights() function from the older resource isn't used anymore. Instead the call to renderMountedImage() is now in ShapeBase::prepBatchRender(). The only problem I'm seeing right away is 'imageData->muzzleNode' doesn't exist so you'll need to find a way to get ahold of the muzzleNode. I hadn't been using this node and all my models have custom setups, so it could be possible as well that you need to create and add such a node. All references to the 'muzzle' I can find at a quick look atm refer to the 'muzzlePoint' which isn't a node but a Point3F position. Let me know how you get along with it and if necessary I might be able to take a closer look. Happy Torque-ing!
  24. I researched around the GG boards as you recommended, Chris, and you were correct about morph support once being there. I found a thread explaining( in a nutshell ) how it was removed due to performance reasons. It was reported that the added vertex data was causing .dts files to become overly large as well. All of that makes sense considering how far back Torque's roots run, but I am certain the implementation at that time wasn't quite up to par with what it could be today. By today's standards, if vertex morphing is handled correctly engine-side it actually costs less performance-wise to apply a morph than it does to animate a bone. Vertex information is applied to a mesh prior to bone weights/animation and never referenced again. I digress. Seeing evidence in Adam's posting( and another I found on GG boards ) that basically just using bones is a norm for Torque re-assures me though. I mean, if you break it down what I'm doing by blending in face bones isn't putting much( if any ) pressure on performance. You start the blend, it 'morphs' the face, and you can even call to stop the thread so it's basically just a bone that was moved once and parked. Heck, in the stock Torque soldier model you've got animated bones for little things like the shoulder pad bouncing as you walk. These blended bones aren't even moving =) Thanks for your feedback Chris. I suppose that unless something glaringly obvious comes up as an issue, for now I'm going to carry on assuming that blend animations are the way to handle this using Torque. Given a greater supply of patience and alcohol, if one insisted they could potentially nab the morph data out of .dae files on import by extending the source code. For all intents and purposes here( a few facial customization options ) I'll content myself with using blends =).
  25. Greetings! Hopefully this is in the relevant sub-forum. I have an inquiry about Shape Keys( more commonly known as morphs ) and utilizing their data in Torque 3D. What a Shape Key( or morph ) will allow us to do is have various arrangements of vertexes in a mesh object. So, just by altering the Shape Key value( i.e. 0.0f - 1.0f ) a mesh can be deformed, squashed, stretched, you name it. I am using meshes with various Shape Keys which hold settings like eye scale, jaw width, etc. for character customization. As far as I could gather, Torque3D has no support for such Shape Key/morph data. I couldn't find any place in the T3D source in which this was implemented. So this leads me to: My Implementation - Blending Since I couldn't find any way to utilize Shape Key/morph data in Torque 3D, I went about trying to figure out how I could adjust a mesh's vertex data on the fly. What I came up with was a sort of 'brute force' method that just uses Torque's existing Blend functionality. So, what I've done is made bones in the model that will adjust certain vertex groups. Then I've keyframed animations to hold the bone's info, like: all the way up is eyeScale 1.0f and all the way down is eyeScale 0.0f. Then I just added those animations to the player object, set all the variables up on a GUI, and set the player to blend those animations into the "base" one. The Question: What I've described above seems to work fine. I've extended the GuiObjectView to support all of this( plus much more =P ) and all seems to be okay. My question is whether or not there is some negative reason I had to increase the max count of threads on ShapeBase objects to blend in a bunch of "customization animation threads". I'd just like to be sure, before I go much farther on this path, that all those simultaneous threads won't be a problem for some reason later. I mean, I manage all the threads( seemingly ) without errors so far and haven't noticed any sort of immediate performance hit. Bear in mind each animation I've blended in this way is extremely minimal in the data it contains. i.e. Only one bone controlling data for one value at a time, like location X or scale. So, has anyone else encountered this and found a good approach? Is there Shape Key/morph support already embedded in Torque I hadn't noticed?
×
×
  • Create New...