JeffR

Sounds interesting, I did not expect that update so soon.

The issues slipped past the testing likely because the testlevel did not utilize much advanced features, the test level has almost no normal or specular maps applied and not a reasonable lighting setup. I would also turn off the timeofday by default, since it confuses the lighting setup, you need a constant scene to have something as a benchmark, not something that changes all the time, this can give wrong impressions.

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.

Thanks for this. I seem to have gotten the code up and running, and I am seeing a split screen in my project on the monitor, but when I look into the rift, I just see a little hourglass icon. Not sure what is going on here, but I will post if I have any useful information about it. (I have a DK2, and get warnings from the oculus software that it's not supported, but it still works with the demos.) I should try this in the T3D directly, not just in my project, and see what it does there.

Yeah, like said, only tried the openVR with the vive, not the rift, but if you spot anything in the logs, or find any details, feel free to post it here and we can try and hash things out.

3.9 functions fine, but there were some rendering bugs and the like that slipped past testing for the release. We're hammering all those out for the next update which should be wrapping soon, as it was mostly about fixups and the like.

You can update to 3.9, then grab 3.10 which will be a much smaller change than going from 3.5 to 3.9, or you can just wait for 3.10 to land first.

The allowed numbers for DBs and ghosts and stuff were bumped up a little while ago, so you can use somewhere around 16k datablocks if i remember right.

So while you don't want to go insane with 'em, as chris and the others said, it's not so low a number as something you have to actively fret on normally either.

Alrighty, put this together from Mango's examples, so pull it down and give this a whirl

https://github.com/Areloch/Torque3D/tree/OpenVRFullTemplate

For the project/engine config, you should just need to tick the advanced options: TORQUE_EXTENDED_MOVE and TORQUE_OPENVR in cmake, hit configure, and there'll be a new option TORQUE_OPENVR_SDK_PATH. Put in the path to the openVR SDK and hit generate.

Recompile and the engine side'll be good. If you grab the link to my one branch and use the changes in the full template, you should be good.

Hadn't tried it with the rift, only the vive, but it should all check out on that front at least.

Lemme know if you run into any trouble spots.

For what it's worth, I use Dreamhost myself and they've been excellent.

@MiToVo

Yeah, I really dislike the current terrain materials deal. Making terrains use the regular materials is on the block for 4.0, because the odd half-n-half materials it has now is definitely less than ideal.

As for the flatten terrain, I think it's intended to flatten at the average point, compared to the set height function, which sets it to an explicit height. But yeah, I can see what you mean about flatten sampling the height when flirst clicked, and then acting as setHeight as long as the mouse is held down. Maybe as an alternate mode for flatten to dictate weither it re-evaluates the height, or just paints-to-height of the initial click.

It can be easier or more immediate to get on other platforms than steam though, where you need to go through greenlight or get a publisher, some of the other stores have fewer hoops to jump through - for better or worse.

I'd say I'm more comfortable with the current editor. May be because I reaaaally know it at this point, but I just like it compared to the older editors.

That said, if you could figure out what makes the TGEA editor so comfy to you, that's the sort of thing that makes for good notes on improving things going forward. An editor you can feel comfortable working with is really important.

Sorry for not seeing your update on this. Somehow it totally slipped past my perusings of the threads.

Anywho. Yeah, if you're ready for it, feel free to toss it up. Worst case, we'll just go over it and decide it should be broken up a little. But obviously we don't have anything against larger changes :)

As for when to make PRs and stuff, feel free to just toss one up if you think it's ready. It'll show up in the github list, so you're not obligated to make a forum post/thread here, though you certainly can if you want some additional discussion/ideas about it.

Cool. So, in order to properly break it up using git, is the typical procedure to make a series of commits in the same branch before pushing/doing the pull request?

For this, I forked the T3D repo and made a branch called "guiSpeedometerHud" (or something similar), then did a commit of all the changes and finally pushed them. I presume doing a pull request would be the next (final) step.

If the changes had been committed to my repo's branch in chunks, maybe as "Fix rendering", "Handle mounted players.", "Add calibration/debugging console fields/functions", and then pushed ... would that break them up correctly to do with a single pull-request? Or is it necessary to do a separate pull request for each bit?

Also, I am assuming that I'd use the same branch for all changes that are being made in relation to this specific control, right? Or is it necessary to make a new branch for each change?

Yeah, that's pretty much the right process. Sometimes it's a good idea to break up really big stuff into completely separate PRs, but for something like this, where all the changes are related and it's not massive, usually just making sure to do the commits in bits to the same branch so it's all documented is perfectly fine.

Does anyone see value in making a simplified version of this control to provide a general-purpose analog dial?

Technically, the hud can be used that way as it sits by controlling the calibrateAngle field in script. It wouldn't take much to strip out the vehicle-specific stuff and maybe add a bit of functionality to tweak it for general use.

Yeah, that sounds like that could be pretty useful.

Stevel:

I hadn't tried the openVR stuff with the rift, just the vive, but as far as I know, it should PROBABLY work.

There's some script-side stuff to add to make sure it renders to the headset canvas and stuff. I'll pull that out and update here for ya to try.

(As an aside, I'm working on making a VRCameraComponent to cut out a lot of these extra setup junk for the future)

Hey Paco!

Alright, as a bit of an update to circle back on this, was able to replicate this and also affirmed it's broken for OpenGL as well(dunno if you were bothering with it at all).

So we'll have a look into this and try and get it patched up. I wanted to branch out the editor to have the option of popping some controls out into second windows, so I think this is a pretty important thing to fix :)

Hey, awesome!

Any chance I could bug you into turning this into a pull request for the main repo?

If not, I'll make one if you don't mind, but it's always good to get bugfixes into the main branch when possible :)

Thanks for your hard work!

Sure, you are welcome to integrate the changes. Glad to be useful. This has been tested in 3.8 if that makes a difference. I'm in a bit of a learning curve with Github - never done a pull request. It would probably be better/faster if you did it on this one.

I've been out of the Torque loop for quite some time and still need to figure out how things work in these Harvard-license days. With stuff like this, is the usual approach to submit it as a pull request and not do a forum post/resource ... or is it better to post in the forums and only submit a pull request when someone asks for it?

@JeffR: With the update, it's gone a bit beyond a simple bug fix now. Is this still appropriate for a pull request?

If so, think I'm set up to properly make one.

Sorry for not seeing your update on this. Somehow it totally slipped past my perusings of the threads.

Anywho. Yeah, if you're ready for it, feel free to toss it up. Worst case, we'll just go over it and decide it should be broken up a little. But obviously we don't have anything against larger changes :)

As for when to make PRs and stuff, feel free to just toss one up if you think it's ready. It'll show up in the github list, so you're not obligated to make a forum post/thread here, though you certainly can if you want some additional discussion/ideas about it.

I just wanted to chime in here to thank @kent for his contribution and sharing with the community. Also thank you for bringing up this same question that has been on my mind for quite some time:

 

With stuff like this, is the usual approach to submit it as a pull request and not do a forum post/resource ... or is it better to post in the forums and only submit a pull request when someone asks for it?

 

For a number of reasons, I personally would prefer not to submit PR's to the T3D branches directly from my company's GitHub account. However, I strongly feel the need to share some of the small updates and corrections I stumble across while developing. So I can either A)make another GitHub account and create an entire fork for each small change then PR it - or B)Copy/Paste the code in a resource here on the forums. It's like if I go with A) it's pretty cumbersome - especially with the sort of scheduling I have to deal with. If I go with B) it seems much simpler although then I feel as if I am not being helpful if I don't go the extra mile and submit the PRs. lol.

Anyways just some thoughts, and I'd be interested in hearing the SC's stance on this. I would prefer to use the proper etiquette when sharing.

I'd say go with whatever's comfortable for you. If you can hock it with two accounts, neat. If you wanna just toss the code up on here or a pastebin or whatnot so someone else can slap together a PR, that's fine too. Much better to have people put code up and take a little bit of additional wrenching to get it sorted than no code at all :)

Maybe if you have something PR-able, you could possible make an issue and link back to the code/post for it to be PRed? That may work.

Heh, yeah, we need a new car model, I think.

For art stuffs, you can snag some foliage/terrain/road art from the pacific art package, and for stuff like signs or maybe even cars, you could look at opengameart.org. They tend to have a lot of public domain/cc0 art stuffs up for use, may be worth a look there.

For basic buildings, you could also use the convex editor tool to block stuff out.

As for using github, this may be useful info, if not lemme know what spots you're rough on with it: http://wiki.torque3d.org/git:how-to-use-git-with-torque

@Bloodknight: I still have access to TDN. I'd love a full archive! :-)

@johnxz: I have a small collection of TGE resources on an old server. I need to fire it up anyhow because there are a bunch of art assets on it. Not sure what's there, but I'll let you know when I do it. Is there a place to dump old resources if we have them to share?

On a somewhat related note, I'm in the process of porting an old WheeledVehicle resource from TGE. I had noticed that the "starter.racing" demo didn't make it into T3D (and, apparently, TGA). and just this morning was trying to decide weather or not to port the racing demo as a part of the vehicle stuff. It was pretty basic, but would probably be cool to have. Some of the vehicle design choices make more sense after seeing how that demo implemented.

Oh man, by all means, bring the racing demo back. That thing was always a blast to just fire up and drive around the terrain like a fool :P

For the resources bits, feel free to either toss that stuff up onto the wiki, or PM me and I can host stuff on my personal server.

Hey, awesome!

Any chance I could bug you into turning this into a pull request for the main repo?

If not, I'll make one if you don't mind, but it's always good to get bugfixes into the main branch when possible :)

Thanks for your hard work!

What's your math look like for the actual offsetting back to origin?

If you can offset to origin and then offset back and it corrects itself, I'd highly suspect there's an odd math operation going on in there that's skewing the values.

Are you just doing a flat vertexPoint -= playerMoveOffset, or do you have something more complex in play?

So you have one window that's the main game render, one that displays a particular render target, and then the others are just regular gui controls, if I'm reading this right?

Will have to take a look and see what'd be needed for a setup like that.

Part of the performance difference - especially on older hardware - is that compared to the prepass lighting of prior versions, deferred shading has a much 'fatter' g-buffer, which holds the information about the scene for rendering/post effects.

So while the workload is somewhat lessened from prepass lighting(less duplication of geometry rendering, for example) the amount of data passed in a big chunk is higher, depending on how heavy the g-buffer is. On modern hardware, this really isn't a problem, but on older or weaker hardware, such as integrated chips, the extra bandwidth load hits it harder than just crunching pure geometry would.

That said, while tracking down the oddities that Duion and some of the others noted with deferred/linear changes that went into 3.9 we noted several spots where the texture format is higher than it needs to be for most cases. So we're looking at trimming down those spots, which will make the gbuffer a good deal leaner, and thus make a solid improvement to performance, especially on older or weaker hardware. Right now the high precision targets being used help things look good, but at the cost of performance, so striking a balance, or letting it be controlled by preferences for those that need/want speed over looks have that option.

It wasn't that, I can get from makehuman to blender using either collada or mhx. (Although I'm sure mhx is preferable.) It was my collada import into Torque code that was causing the current problem, however.

Oops. :-)

Ah, interesting. Well, at least you got 'er cracked :)