JeffR

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.

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. 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 :)

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? 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. 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

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.

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

Pretty neat. The first 3 look like I'm in various stages of an acid trip, haha. That last one's pretty slick. Any custom shaders happening, or is that purely a custom color correction ramp?

In blender, take care to make sure that your mesh and armature have any rotation and location changes 'applied'. Having the transforms at non-0 can look fine in blender, but yield really weird results in-game. Just the other day I was testing character models/rigs and had the guy turn into a spindly slenderman horror-beast because the mesh had been rotated and the armature hadn't, and it tried to 'compensate'.

I'm the main programmer on board at this point, and I've worked an early-build MMO client-server model from our previous attempts at the project into something somewhat standalone, and I want to work it into Torque, but I can't get it working. I'm wondering if the built-in networking component is what's getting in the way. I would rather strip out what's in Torque and work in a fresh new version of what we've made than try to get what we have working around what's already there and ignoring it. In fact, doing so, according to a couple of people I know networking from the college, is considered a (albeit non-defcon) security risk. I mean, they could be wrong, they aren't industry pros they're mostly info security in corporate settings, but I still think they probably have a good basis on the thought. Unless someone has a suggestion on how I could somehow rework the built-in networking altogether, that's what I'm looking at. Would I benefit from making that client-server model a plugin to the engine versus built-in? I would think that too would be a security risk versus just going full into building it into the engine and thusly client. If that makes sense, please shout if I'm not clarifying right. :) Details for the particular setup you're shooting for would be useful, but on a basic level, I'm not sure how extreme a security risk an uninitialized and unused networking layer would be. For example, if you wrote a custom game class that worked with your custom networking model and doesn't interact with the built-in packet handling in any way, then any theoretical bits exposed that could be set couldn't really be utilized to mess with the custom game class. If your security buds have specific points of concern a la security, those could probably be addressed, but if your stuff doesn't interact with the existing networking, I don't think it'd really matter much.

The jump from prepass to deferred will reduce the polycounts rendered, but offset the potential gains there with extra bandwidth costs in setting up the gbuffer and the like. In your average scene, performance is likely to be about the same, but deferred shading scales better when adding more lights and post process heavy effects.

Something along those lines, yeah. The actual changes, as Lukas has pointed out is really just exposing and tweaking an existing interface in the engine to make it more flexible, but the idea is it's an additional option for people to work with if they want to work with it, but not an obligation.

If C# does get implemented, it won't be at the cost of TS. At minimum, the core configuration and tools are in TS and that's unlike to change in the future. Much like enabling multiple sound systems and multiple physics engines, the idea is to add a framework to let the end-user have the option that suits them best. C# is very unlikely to go anywhere, and if you don't want to use it(if it gets rolled in in the end) you can just continue using TS as usual, but having it as a potential option may well be more appealing and comfortable for some people.