JeffR

I just tried the RC binaries. I hoped performace would be better, I am running on a I7 6700HQ 6th gen, 16 GB DDR4 RAM and a Nvidia 960M 4 GB videoram notebook. In the outpost Level I get only around 35fps, in the desert around 85fps., running in 1080p fullscreen. Are the fps supposed to be that low on such a system? I also tried an old demo of beamng, which uses torque3d as well, and there I get better frames (a little).

What kind of fps do you get?

Are the settings maxed out? Also, what graphics API are you using? D3D9?

Hey Guys!

Was hoping to get this out the first week of December, but when ya find bugs, you wanna fix bugs.

So here it is, the RC for 3.10 (Updated to point to RC2)! The prime emphasis on this release was fixing bugs and shoring up some stuff like some of the lighting maths, but we also squeaked in a few new additions as well. This like updating the Recast lib to latest, as well as the initial implementation of Ipv6 support and swapping the main audio device to OpenAL-soft, which is much better than the old OpenAL, OpenVR support for the Vive and freaking MacOS support!

Tons of fixes went in, including getting collada exporting fixed up as well as some utlitiy functions to bake a bunch of static geometry like convex shapes or meshes, into a single mesh, which can help a lot on performance with complex scenes, lots of fixes and tweaks to lighting stuff, as some of it didn't play well with the new linearized math under certain conditions - especially dark maps.

As the last time, RC testing will probably run until the end of the month-ish unless some crazy stuff pops up, and then we'll push onto 4.0. I'll have the Linux build uploaded tomorrow.

I've been working on a 'master thesis' post about what's the target for 4.0 and what'll be going into it, what's already done and what's yet to do. Hopefully you guys'll like where things are headed, but untill then, test the crap out of 3.10 so we can make sure we've got a good, solid foundation for fording the rivers on the way to 4.0!

Hey ben,

Can I get some screens of what it looks like when you lower the near plane? I hadn't tested that. The acne/artifacting for the cube shadows is definitely annoying and will get some TLC.

The gaps you see in the parabloid shadows are 'working as intended' though. Not even being snarky. The way it calculates those is by mapping a sphere to two, or even 1 render target(which is the idea behind the 'single pass dual parabloid'. It's really fast, but due to the distortion of the render to make the hemispheres work, you get gapping at the seams.

Those are great for fast lights, like gunfire, but definitely not as idea for permanent lights like lanterns or the like.

Haha, yeah.

I'm doing up a GUI interface to select the benchmark path, that'll go in today, but otherwise yeah, feel free to hammer the crap out of it and suggest things the benchmarker should record. It's perfectly extensible.

If you're only trying to set the position of the gui control, you should be able to just call setPosition(mPtScreen);

if you poke through gui/core/guiControl.h, that's the header of the root gui object class, and that sucker has a ton of useful utility functions for doing basic stuff like this.

Lemme know if that doesn't work, but that should do what you need.

Oh wow, sure enough, there's at least the rain one floating around.

Yeah, that was the old format to get you stuff like animated rain splashes or droplets. It's deprecated, so we don't really want those floating around. Nice catch!

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.