Requires adding a windows environment path var to the SDK, but after that it should detect and popular correctly.
However, as that's kinda clunky, we were looking at possibly just having some cmake libs that generate the physX SDK projects if physX is selected, so all you'd have to do is drop the physX SDK files into a engine/lib/PhysX directory and punch the option and it'd chug through.
But that's not quite ready for primetime yet
For now though, either manually adding the stuff to the project, or use the linked branch above to hook it into cmake. By the way, it's intended for 3.x
Me and Timmy started re-poking at the nodegraph stuff, looking towards plotting out the new shadergen and the visual editor for it.
It's super rough(and timmy's nicer-looking bezier curve lines aren't in yet), but here's the ultra-preliminary mockup of that underway so far:
It's rough, but you can see the foundations for it. The idea being that we'll have several different end-nodes(like the PBR Material one in the video) that would inform shadergen the type of material/shader we're going for. This will set up a bunch of supporting stuff and limit down the stuff that can be used that work with that material type to streamline everything.
Eventually, we want to make it where you can write totally arbitrary shaders and even postFX in the interface as well, but first-thing would be to get it to work with the most common, hard-surface material type.
One thing I've had sitting around mostly done for a bit with the e/c stuff is a State Machine component. General purpose, designed to just function as an all-purpose state machine you'd build on top of for weapons, AI, etc.
The issue being that writing state machines by hand kinda sucks, so to really make it work, you need an interface. Well, with Timmy lighting a fire on the graph stuff again, it looped back around and re-tackled the web node graph UI and also the supporting state machine editor scripts.
It's still got a ways to go, but this video should give a pretty solid idea of how it'll go:
Given that the variables, rules, states and transitions are all arbitrary and what you want them to be, you can pretty much build any kind of system with it using this as the base. You could write an animation controller that's state-driven like Unity's mechanim(which is one thing I've planned to do for a while now), a weapon's state machine, AI, etc.
In the end, it should be pretty powerful, and fast to use to boot.
Also, mac support inches closer, with rendering and driver issues getting hammered out. It's not there yet, but it's definitely approaching on the horizon
@ Janders: If you can think, and you can type, then you can code! Whether or not it hurts your brain enough to make it not worth doing is up to you. I know the pain, let me tell you. But you can code if you decide you want to bad enough.
@ JeffR and @ Timmy, dammit you guys rock so hard! Many kudos and beers to the SC and all contributing developers!
@ Steve_Yorkshire I am a level 15 Wizard! Fear my baleful code polymorphism spells!
Hey, even if you can't code(and stuff like the graph editors are designed for peeps like you and as chris said, it's entirely possible to learn. ), art, testing, feedback and ideas are always great ways to contribute as well.
Among the several other bits being worked on at the moment, such as Timmy doing a beatup on sRGB stuff and our double-checking on HDR/gamma shennanigans, as well as trying to catch the last few weird-bits for the hardware skinning, I've been doing further crunching on the new asset pipeline stuff.
So here's a video showing the asset browser and stuff off a bit more:
As you can see, there's a fair bit of functionality going on in there now. Once can easily import in art, or create new components or state machines, and immediately jump to the respective editor or Torsion, for script-based stuff, and immediately begin working.
The 'refresh asset' function only currently works for script-using assets, but lets you modify and reload the script without needing to restart everything which is obviously awesome for iteration time.
Still quite a bit to do, of course. The creation/import and organization of assets needs further refinement. I didn't show it off, but you can just right-click in the asset browser's main window, off an asset preview, to get a pop-up to create a bunch of regular types.
I also got part of the renaming functionality in there, but it's not quite ready yet, but you'll be able to just right-click, punch the rename option and type the new name of the asset and have it update all the respective files for you. Stuff like that should go a LONG way to help cut down on stuff like case-sensitivity issues on Linux.
Also need to add more options for management of Game Objects and assets, such as duplicating an existing one, or moving around what module they're a part of, but this is already a very long way along!
Another thing that i've been bumping up against that isn't really in the way, but definitely going to need some tweaking is the editor settings. What i'd like to do is expand that option to be 'Project Settings', which will be a full-blown menu to adjust settings for the game, such as options settings/groups(so you can tweak what your low/med/high settings involve or the like), paths for common things, and potentially a menu for setting up your default keybinds and what functions they call to help simplify setting those up.
So yeah, quite a bit more to do, but it's becoming easy to see where the asset pipeline is moving towards, and it should be a lot easier and faster to use than the old one.
Oh, also, if anyone has a suggestion for a default icon for stuff like 'Game Object' or 'Component' or 'State Machine', I'm not a fan of the text-n-color setup that's there now, but the itty-bitty icons included with T3D weren't really good enough to work with atm.
So, lotta work's been hapening, so lets recap on it!
First, hammering on PBR has been happening, fixing up the fresnel maths and the like. Here was a fun shot compare poor, old non-PBR T3D soldier against a model that actually has the proper PBR materials set up:
It's not 100%, but it's definitely starting to look proper. Make sure to pass some serious love at timmy and Az for being the beasts that hammer on that.
For my part of the PBR equation, I've been working on reflection probes, which is used for setting up the reflections for PBR materials and will be used for IBL/Indirect lighting as well.
The video is a touch out of date, but it shows the basic idea. The probes render their data, which can be anything from 2 horizon-blended colors, to static cubemaps, to baked cubemaps and eventually fully dynamic reflections, and render them out to the indirect lighting buffer. The sharpness of the reflections rendered are based on the materials' roughness and roughness settings. The best part about these reflection probes, is unlike the cubemaps of old, it's completely detached from the materials and objects, and dynamic objects moving between the influence areas of probes will blend between, reflecting automagically. They're all sphere shaped currently, but I'm going to be adding a 'convex' mode as well, which will start as a box, and then I want to integrate it into the polyhedron-conversion functionality of the editor.
So you'd have your box area the reflection probe influences, and then convert it to a editable convex shape and modify it's shape to any convex shape you want, then switch it back. This is useful for oddly shaped areas(like say, sloped ceilings) without clipping through the other side. I want to implement the same system for lights as well, which could be used to edit static lights and prevent light bleeding situations by just modifying the light's shape so it can't ever clip past the wall.
Also been working on PBR-ifying old art I had for the test level seen in that video(as most of the materials aren't properly PBR and thus don't behave very well). We've talked about it before, but the Allegorithmic tools are a godsend for that. Being able to drag-n-drop a regular image and get the PBR-friendly materials out the other side is pretty excellent.
Other work's been done shoring up issues run into with 3.9's release, namely poor behavior in regards to non-HDR scenes - specifically the dark ones. We're testing a few final PRs that should but the kibosh on most of those problems until we gut DX9 and can roll in proper sRGB support to sidestep the entire gamma/linear mess wholesale.
Timmy's been doing a huge amount of incredible work getting all that stuff hammered together to have it ready to flip the switch when we kill off DX9.
That said, given the issues that cropped up with 3.9 that snuck past testing, and several new bits that have been rolled in that are a bit too good to wait on(including the soon-to-be-merged OpenVR/Vive PR courtesy of Mango's incredible work and his Hardware Skinning stuff that was recently merged in), we're going to bring together a 3.10 release to put a lock down on things before we get to the major works for 4.0, such as the jump-over to Entity/Components/GameObjects, Assets, PBR, and so on.
If you wanna play around with what's basically the hyper-ultra-probably-half-broken cutting edge, I've got my massive, massive R&D Branch you can grab and mess around with most all the stuff I mentioned above now. As stuff is refined and finalized, it'll get PR'd and merged into devhead, obviously.
I also started a twitter, which i've been doing smaller, more constant snippet updates too if you wanted to check that out.
We've got a few more issues to put a clamp down on, includng the shadow/normal acne banding, some problems with cubemap point lights and a few others(thanks to all you guys finding and noting these issues!) and then we'll get 3.10 out the door and begin the proper slam-down on 4.0 and kick the rollercoaster off proper!