-
Posts
1011 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Articles
Docs
Gallery
Posts posted by JeffR
-
-
To clarify on it, with the spacing correction back in there, does it still not import correctly into blender without first passing it through FBX and OBJ?
-
Generated it via cmake
-
Shadergen just generates the procedural shaders.
The material classes are largely what act as the binding between the shaders and the classes to be rendered for the procedural shaders. Classes that utilize the common, pre-written shaders like the water classes just call to the shaders directly.
-
@kylehagin
Namely that breakpoints aren't triggered, so I can't stop the application in certain areas, check variable values, etc.
Does ddd allow for that?
-
I'd made a passing mention of it in the 3.8 announcement blog as a goal for 3.9, but the plan is to start work on a node-based material/shader authoring interface and an updated shadergen.
I'd gotten started on the node-graph ui stuffs, most of the work is trying to figure out exactly how to design the new shadergen system to operate to generate everything. I've got some stuff I'm doing some prelim R&D on the subject for, and once I have something a provable, I'll be posting an update about it.
If you guys have any ideas or feedback on how you think it should operate, I'm completely all ears. If we can hammer out a general approach, it'd be easier to iterate the specifics of the implementation.
-
When you're experiencing the 'locked' behavior, was it after trying to select something by clicking on it?
I've found that occasionally, when I've been clicking on other parts of the UI, or switched windows or the like, the cursor may think it's been clicked and held, causing it to act like a drag-selection, and multiple things get selected.
-
Does that happen only when you edit the terrain?
Or does falling through the terrain happen even if you save, exit, and reload the level?
If it's the former, could just be that when you add that third material, it's triggering a rebuild of the terrain block, and the collisions are wiped momentarily, but I'd need to know if it's ONLY during editing to be sure.
-
We don't have a form, if that's what you mean, but creating a thread here or an issue on the github page'll work.
As for the information, if you can do a video or the like, that's provide a lot of information, but really all we need are the steps to reproduce the problem. Anything beyond that just makes things easier.
And yeah, if you compile the engine as debug, that tends to give you a bit more information as to whats going wrong, so it's usually a good idea to do that when you're noting issues.
A console.log is always help, too.
-
Well, you said manually compiling it all yourself ran without problems right? So the only issue was the precompiled?
May just be a compatibility issue between distros. I compiled the precompiled one on Ubuntu.
Jeff, Correct. Under Linux Mint 17. I'm not able to run the precompiled version. I'm able compile, and run the versions from the github site. Can I assume that the Master branch is the latest release (3.8)? Is it possible to see which version I'm running from the editor?
Thanks!
Correct, the master branch is 3.8.
As for the version, hm...I don't know that there's anything that has a version readout in the editor, but I think there really should be. Good suggestion.
Also, wrapped the release notes!
-
@Krakean
Yeah, finishing up the release notes completely slipped my mind. I'll make sure that happens today.
-
Well, you said manually compiling it all yourself ran without problems right? So the only issue was the precompiled?
May just be a compatibility issue between distros. I compiled the precompiled one on Ubuntu.
-
Just watched the vid, and wanted to say:
<3
-
I only have 2015 installed on my main desktop machine, so I'll see about trying to replicate this tonight.
My guess is that, given the mention of the DXErr lib, is T3D still uses the old DirectX SDK, there may be some hangup there. Getting it switched to use the WindowsSDK is on the to-do list in the near future and could fix that.
-
Actually, getting that stuff to avoid roads should be pretty easy.
DecalRoad has a 'containsPoint' function, where you pass in the worldPos and it does some quick math to see if the world pos falls inside the road segments(and will return back the node in question, if it matters)
So when generating the grass or trees, you should be able to get the intended x/y position, use get terrain height for the z, and then iterate through any decal roads in the mission(should be able to early out by testing it's bounds vs the current ground cover cell, and if they don't overlap, skip it).
Then just pass in that pos to the potential decal roads and see if it falls inside any of them. If it does, reject that grass item.
MeshRoad almost has similar, it has a containsPoint for the MeshRoadSegment struct, so you'd need to add a containsPoint function to MeshRoad that iterates through all the segments, but otherwise it should be a repeat of the above with the decal road.
Do that, and you should be able to easily reject the position if it'd overlap with a road.
-
Looks pretty slick!
If I had a critique, it's that the human models look a little to clean and perfect, their armor especially. A bit of wear and tear on it would make it feel more 'real'
-
Yeah, hair is always gunna be tricky to render in a satisfactory way, I know even MGS5 just pretty much went 'screw it' and doesn't render the hair shadows.
Can you post up a shot of a cranked up alpha threshold? That's usually the go-to on doing transparency like that, so it not working properly is kinda odd. It may be a texture format issue or something.
-
@triggerfish
How'd you make the project files? CMake?
And what'd you use to compile it?
-
Well, SDL was compiled dynamically for the binary, and the so files are in the directory with the application file.
Wondering if there some kind of path issue...
-
That sounds excellent.
It'd be nice if we could get it to project shadows too, but that's a whole different can of worms.
-
@MilkywayM16
That looks good already. Definitely a much better sense of volume. Can you control how much coverage it has? One thing I dislike about the current cloud effects is it's hard to get a totally overcast sky.
-
@saindd
Shadergen is what creates the shaders for you when you use the built-in material editor.
When you make and use a material, it still requires shaders to render all the effects you add via the material settings, such as normal mapping, specularity, animation, etc.
Shadergen is the voodoo in the background that reads the material settings, and generates a shader file for you. It's a solid system, but it's kinda rigid and not easy to expand.
Shadergen 3 would allow a lot more flexibility when setting up materials and let them do fancier, custom effects if they need them.
(Ahh, ninja'd by Az ;) )
-
I touched on this in the 3.8 release thread once I got an OK to mention it.
Timmy's been doing work on Anis' DX11 and D3D9 refactor branches, to get them updated and rolling. He's been getting his work uploaded, and once it's all up, he'll open it up for everyone to help collaborate on. This should get us a baseline implementation of DX11 - it may not see tons of performance gains at first, but we can steadily improve it as we go. Having it in at all is the big first step.
-
Also, double-checked with him as I didn't want people to try and pressure/nag him about it, but Timmy was cool with getting a mention.
Timmy's been working to get his work on Anis' DX11 branch put up so we can all collaberate on getting it in, hence why DX11 is mentioned as being a target for 3.9.
I think everyone is in agreement that getting DX11 in is gunna be required, going forward, and Timmy's put in some starting work to get Anis' original DX11 and D3D9 refactor stuff updated so we can all jam on it.
With a bit of luck, he'll have the rest of his changes all put up into a branch so we can get it shored up and rolled in :)
--
Also wanna mention that JeffH and glenn and Az have been crunching rather hard trying to get OSX working. They've made startling headway the past week, and with luck the remaining issuse will get stamped out and we can get mac support back in the engine proper as well.
-
Hey everyone!
Today we'd like to announce that 3.8 is now out in the wild! It's been pretty fast paced all in all, with us burning through it in just over 3 months. As mentioned before, this release was largely focused on trying to shore up on the stability front. While it's obviously impossible to ensure any software is 100% stable on every machine, we've noted a definite improvement with the work that went into 3.8.
We managed to pull in well over 70 PRs, some of them being fairly hefty. SDL got a lot of TLC to get it shored up for when we switch over to that as the main of our platform layer down the line, and Linux got a good bit of additional attention to get it in a much more solid state. Of course, there's always more work to do, but a lot of headway was made.
I'd like to put a shout out to the people that PR'd changes that helped us get here:
- Az
- blackwc
- Duion
- buckmaster
- raistlin
- Mango
- rlranft
- John3
- MusicMonkey
- JeffH
- Lopuska
- pacomont
- Timmy
- signmotion
- and the guys at both Winterleaf and BeamNG
Your contributions all went into this update to help improve things for everyone, so thanks a ton!
So, where can I get this lovely release?
A fine question that a smarter man would have addressed sooner!
You can get the release with binaries for either Windows or Linux from our downloads page on the wiki, here.
Remaining issues
One remaining issue that I tried to get wrapped up, but was unable to because, well, I suck at Linux'ing, was the issue of file dialogs. It was something we'd missed with 3.7, and so for 3.8 I tried to find some cross-platform library we could utilize to get us native file dialogs for linux, and eventually OSX.
Unfortunately, I couldn't get Codeblocks to let me actually debug things, so there's a few niggling issuse causing a crash somewhere with my implementation. I've got a branch concerning it here and if anyone can either tell me how to get codeblocks to properly debug, or can figure out the crash themselves, I can PR it right away and get a hotfix out to re-enable file dialogs for the Linux build.
Alright, so what's next?
Now, we take some time and properly draft the minutia of what we're planning for 3.9. That said, we've already got a pretty solid idea of the major hits we're shooting to implement.
Here are the major features we're looking to get in for 3.9:
- New Project Manager that works on all the platforms that T3D does, and uses CMake as it's generation back-end, but a sleeker, easier to use front-end.
- Deferred Shading
- Initial integration of the Entity/Component stuff, alongside existing game classes
- Taml/Asset/Module systems
- Beginning of Shadergen 3.0
- Shadow Caching
- Initial DX11 implementation
- Hardware Skinning
- Numerous tool improvements
- More work to make SDL the primary platform system.
- OSX Support
Wow, that's quite a bit of stuff
Indeed it is. Of course, quite a lot of it is a good ways along already, and some stuff is just waiting to be PR'd or is ALREADY PR'd and just needs to be merged in.
That said, we are looking at 3.9 taking a bit longer than the rather quick 2 month timeline we'd set for 3.8(+1 month testing the RC). Nothing absurd like "See all of you in a year!", but it taking more like 5 or 6 months wouldn't be mindblowing.
Of course, if we can get it done faster, I don't think anyone will complain ;)
As always, if you note any issues, please make an issue on the github page, and if you have anything you'd like to contribute or suggestions of things you'd like to see, by all means hit us up on the forums, we'd love to hear feedback!
And here are the release notes.
Have a good one, and happy developing!
- Az

Torque 3D 3.8 Released
in Torque 3D Announcements
Posted
So, given how weird git can be, you guys may not be familiar with an easy way to pull and test PRs.
As such, I've started a new wiki page and added an instruction set for utilizing TortiseGit for pulling down PRs, here.
Anyone that's familiar with other methods or tools is encouraged to add onto that page with a new section.
Like the page says, the more people we get testing on the PRs, the more assured we can be that they work properly and don't introduce any new issues.