JeffR

Yeah, pretty sure it was just that it hadn't been added yet, not that there was a reason for it not to be. Thanks for filling that gap, guys :)

Haha, no worries. You'd add this to the shader code for the terrain block class. The shader addition itself isn't hard, of course, but you'd also need to add in the grayscale texture to pass in from the C++ code as a shader const handle, as well as the time delta float they mention to make it scroll. I'd suggest starting by looking at the terrRender files and finding how it handles the setup and binding of the shaderConst handles. Those are basically the connection between the C++ object and the shader and how you'd pass stuff to the shader. But the idea being you'd add a new texture2D handle for that 2x2 grayscale image they mention, and a float handle for the fCloudOffset he mentions. Then during the terrain render function, you'd just increment the fCloudOffset. Then you'd add the snippet from the page to the vertex shader for the terrain as well as the texture2d and float from above so the snippet can actually have the data to work with.

This is really, really cool. One of the improvements I'd had slated was a generification of the TSControl view and the cameras with the move to the entity/component stuff and less hardcoded to game connections(similar to your goal with the GuiCameraView). Idea being you could just point the gui control to a camera, and the camera would always be rendering to a target and poof it just works. Sounds like you pretty much went for the same sort of deal, so this is pretty awesome to see you got it working already. This'll definitely need to be standard in the engine. Any chance you could PR the fix and stuff so we can get that in? (As an aside, the hall-of-mirrors portal effect looks pretty slick)

Can you clarify the difficulty you had with getting it working? Changing the painting on the terrain SHOULD(the most dangerous of words, haha) have gotten it to locally update the distributed ground cover, so if it didn't, we can try and dial in on where it's going weird. Did you get the painting part to work? If so, is the ground cover not updating when you do it?

Thank you for your continued hard work and contributions! Good to hear you strive to keep the rates reasonable. Music's definitely one of those things where it's hard to have a gut estimate on how much custom work is(because music is hard!).

Should be for the most part outside a few nitpick changes we're tossing around(like the removal of the dynamic refresh rate control for shadow caching) The math for the linearized lighting should be pretty much correct now and as far as we can tell the banding has either been drastically reduced or removed. So yeah, I spent this weekend moving into a house, so now that that junk is out of the way, we can put a wrapper on this this week. One a few outstanding 'major' things, the big one being a double-check on an intel-specific issue with the GLAD OpenGL API PR, and some math that got tweaked at some point for the terrain shaders. Beyond that, it's just a final go of testing on some of the outstanding PRs for fixes/improvements, and we'll have it ready for a release candidate to get put through the ringer.

Ah, gotcha. I'll see about getting that updated. Thanks for the spot!

Hey, that's pretty slick! Nice find.

Sorry, just for clarity: Where exactly are you clicking and/or what's the URL that link is trying to go to?

Yeah, we'd been mulling on how to better present the metrics for the 'stages'. The main thing is that during the static update, you have the deferred render, the dynamic shadow render, and static shadow render all in the update, so the poly count rises. So for better, more readable numbers we'd been discussing having separate entries displayed for that kinda stuff, like: Deferred(800,000), Dynamic Shadows(200,000), Static Shadows(200,000) or something similar. If there's a particular way of formatting that sort of thing you think may help, feel free to toss a suggestion.

Depends on what you want to change. You could change the various static fields, which should trigger network updates and propagate to the client(though you may see the grass dissapear and re-populate). Is there a particular thing you're trying to change/edit?

Nothing wrong with the idea. Mainly just a "where would we put it" thing. Would we have a separate main forum in the T3D section, or a sub-forum of Blogs, like how there's the Showoff. Any preference about where to put it?

Most excellent of works, good sir!

Love that dude's breakdown blogs. They're super informative. And yeah, Doom's hybrid forward/deferred approach is really interesting. The biggest negatives of deferred rendering is a) translucency handling and high GPU bandwidth costs. Them having most rendering in forward helps deal with both of those limits pretty neatly, without giving up the ability to do post processing effects entirely. Those id guys be smart, yo.

I think a pretty good system would be that if anyone requests a tweet on the forums, or maybe has a promo/dev blog post here, then that's perfectly fine to throw a tweet up about. If anyone has complaints about that, feel free to point them to me :) OT: Pretty cool it got greenlit!

There's definitely some good responses here, but I figure I'll toss a hat into the pile as well. More info for consideration is always good! Networking: While it's true that T3D handles everything as networking, most of that is kinda obscured away from you while scripting, normally. In base terms, if you're writing gameplay, you'll be doing scripts in the server side, if you're doing inputs/gui, you'll be doing scripts on the client side. Then you just have some commandToServer/Clients sprinkled in to bridge between them as needed. But outside of that, you don't often need to fret on where's what in relation to server/client unless you're getting into some fancier behavior. Doubly so if you're only doing a single player game. Template The existing templates do a decent job of getting you set up with a basic framework for gameplay, the networking and some starting content, but the path the scripts take are intermingled and kinda confusing. It's been mentioned, but I've got a draft for a new template based on that t3d-bones one that's more fleshed out and utilizes the modules system. Some changes are coming to it to further refine it for it's integration for 4.0, but if you wanted to have a poke at it, it's here: https://github.com/Areloch/Torque3D/tree/BaseGameTemplate Entity/Components There's an experimental implementation in T3D already as of 3.9, and as covered in the roadmap, it'll be the primary system for 4.0. I really do like the e/c method because it cuts back on duplication of code and keeps things broken down and managable, as well as letting you build out custom objects without being obligated to jump into the source code. I'd suggest giving a skim of my work blog, as I do a fair bit of talking about that kind of stff, as well as PBR and other WIP stuff we're doing with the engine for 4.0, here:http://forums.torque3d.org/viewtopic.php?f=8&t=159 If there's anything else you're curious on, or would like some more in-depth breakdowns on, by all means, ask. We've got some rather knowledgable people here, and we're totally keen to answering questions :)

Do you see that with the current epoxy as well? We'd noted that there's some sort of issue with the rendering/clipping on imposters in GL before, just hadn't tracked it down yet.

Very cool man! Looking forward to this :)

Yeah, getId or getIdString should be what you want.

Indeed, the new test level will need to properly capitalize on the asset usage. As for lighting, I'd say you partially right. The time of day is useful for a quick comparison on the lighting conditions, and to make sure that the feature works, but you're right in that it's hard to properly nail down points of comparison because it goes by quickly. I'm thinking the new tester level would have the time of day on by defualt, but when we execute the VUT, it pauses it and sets it to certain times, like noon, midnight, dusk and dawn, to make sure the values are expected at different lighting conditions.

An issue that @Azaezel encountered with 64bit builds is some data shenaningans lead to corruption and cause explosions. While tracking through that, we noted some ugly pointer voodoo in some spots in the networking in game object classes - specfically pertaining to datablocks - to do some trickery to pass around the datablock ID. It largely works, but is unreliable and just generally a poor approach to passing around the datablock IDs. Branch: https://github.com/Areloch/Torque3D/tree/DBPacingWIP So, the above branch is a WIP testing some cleanup to cut down on the ugly pointer usage, which is to use some functions already in the engine to get the datablock ID and pack it to stream in a cleaner way. All you need to do is merge it in, and ensure that you don't spot any odd behavior, errors, or stuff failing to reference/spawn. If you do note any issues, please post logs, what objects/datablocks tripped it up.

Pull Request: https://github.com/GarageGames/Torque3D/pull/1766 While Epoxy's proven it can work better than glew, it looks like it's older and not supported compared to Glad, so we're looking at swapping over to Glad for the OpenGL extension tracking and the like. Grab it, fire it up on OpenGL and note any issues or errors as well as your hardware config so we can see if there are any hardware/driver issues that'd cause a problem.

Initial setup for Mac OSX support. Pull Request: https://github.com/GarageGames/Torque3D/pull/1785 Compiles, runs, plays. We've noted performance is lower than other platforms, so if you guys can provide additional metrics on differing hardware, we can try and narrow down where the major bottlenecks are. Most of the mac devices just don't have that good of hardware or drivers for OpenGL, but there are no doubt some bottlenecks that can be found and fixed all the same.

@Chelaru Glad to hear it :) To help deal with subtle rendering issues from slipping past us in the future, I've been mulling on a visual unit test system, of sorts. One thing I've been trying to hash out is a new test level that better covers the features bases so we can fire it up and test stuff and know if it works. However, in the case of the linear lighting issues and similar, the issies are often subtle enough that they're hard to catch. With the work on the reflection probes, they can be utilized to capture cubemaps in the scene, which got me thinking of a Visual Unit Test, as said. My thinking is that we have our test level which acts as a sandbox for just about everything in the engine. We then establish a script that iterates over points in the scene - likely via camera bookmarks - that then go and capture the view from that marker, potentially even in a full cubemap format. With a main release, we can establish a new baseline set of captures from these points, and then when we run our VUT, we use an image comparison tool such as Image Magick to compare the captures at the time of the VUT run to our baseline. This will highlight changes, even incredibly subtle ones, and so if something like lighting changes, or we get color banding, this will become immediately apparent in the comparison results and we can figure out if it was intentional or not.

Hey guys! As we work on all the new doodads and baubles for 4.0, which includes an overhauled shadergen, more progress on PBR, new asset pipeline and other neat things you can read about in my work blog, due to some issues that cropped up with 3.9 we've also been doing some improvements and bugfixes for a 3.10 release in the short term. While most of the stuff that went into 3.9 was solid, some issues, particularly related to the linearized lighting changes, slipped past testing and were causing some grief. So those have been hammered on and we have some PRs in testing to try and remedy the major issues that cropped up. I'll be adding some new threads in the development section so we can try and hammer out the last issues and a handful of new features/improvements, but 3.10 should be ready pretty soon, as a good incremental update to the work being done on 4.0.