JeffR

Hm, that's not a bad idea, though it feels like it may conflict with the blog section if they wanted to post about updates there?

Well, part of the problem of picking a tracking software, is there's a lot of them, not all of them are good, and everyone has a difference preference, haha.

Let alone trying to keep everyone aware of what sites have what already as it is. As such, I went ahead and started up the Torque 3D Development forum in the main T3D area.

This will let us give more pointed direction to what issues, features or pull requests should get the priority for people that want to contribute can pitch in on. I've already created a stick in there that gives the basic lowdown, but the threads in it will be created by me and tied to a particular issue, feature request, or pull request that needs attention. As these are taken care of, the thread will be closed. This should make it a lot easier to keep tabs on what the priority stuff is.

I want to make a new entry to the 'how to create/submit a pull request' wiki page that isn't command-line instructions before that really gets opened up, but this should be a decent intermediate solution for now. It keeps everything localized to here, with relevent links to the wiki or github, while keeping things a bit more organized as to what should be looked at first.

Also, Blood raises and interesting point with trying to remember who's good with what in some cases if you wanted to ask someone that may have a better idea. If no one would have complaints, we could look at having some notable "experts" on certain things be referenced in the sticky, so anyone wanting to pitch in on a relevant issue or PR could know who may be a good match to talk to if they need a second opinion on something. Does that seem like it may be a good idea? Or does that seem like it'll get a few people a deluge of PMs and just annoy them?

This sticky thread will be a primer for this sub-forum, and how you can help out with Torque 3D!

This sub-forum is intended to only have threads pertaining to current issues or feature requests that need a fix and Pull Request made, or an existing PR that needs testing before being merged into the engine. For issues, feature requests or pull requests that are deigned to have priority, they will have a thread created in here pertaining to it. This gives a more local place to inform if something is being worked on, or any discussion/inquiries about it.

So, how can you contribute?

There are two main ways.

• If the thread is about an issue, or feature request, you can submit a fix or implementation of it and create a new pull request.
   
  
• If the thread is about an pull request awaiting testing you can pull down and test the PR, and report what, if any, issues you encountered.

This will expedite important issues being resolved, as well as fixes and features being rolled in!

If you're unfamiliar with how to utilize git with Torque for creating or testing pull requests, there's a wiki page that consolidates most of the necessary information here:

How to use git with Torque.

Once an issue has been handled, or the PR has been merged/closed, the thread pertaining to it will be closed. This is intended to keep what needs to be worked on clearer.

If there is an issue, or a pull request you feel needs handling that isn't in here currently, or you feel there's a problem with a previously handled one and it should be revisited, feel free to contact me and let me know so it can get set up in here!

That's really cool!

I'm personally holding out for the attack choppers, but it's definitely cool to see it in action there. Can notice a bit of the chop as you mentioned, but overall it seems like a good baseline.

I used the latest devhead build, and was able to import and paint without issue.

Do you happen to have a base map example I can try and import with the terrain and see if that triggers anything?

Is this a debug or release build?

Do you have the console.log file? That may shed more light as to what broke.

Very cool!

Also, as a heads up, you can format a block of code via the code2 tags, like:

Open the block with code2=cpp, for cpp-style syntax highlighting(with it in brackets, of course) and then close with /code2(also in brackets)

Went ahead and did that for your post :)

Sounding pretty good :D

So what part of it doesn't look correct, to you?

Not saying you're wrong, just trying to understand what you feel is off about it.

Don't have access to one, so that limits the options a good bit.

Mango seems to be the guy that's got access to all the VR toys, so he may do that at some point, but I don't believe that anyone is actively working on it currently. If we could get our hands on the hardware and stuff it'd be worth looking into though!

<3

I've implemented a few small editor deals since then and it hadn't been as profoundly terrible, so I think part of the difficulty stemmed from bugs that had been fixed.

That said, I feel there's a better way to approach the entire thing.

The first that occured to me was basically rather than swapping the UI's around, the world editor UI is always visible, but it has callback hooks to a Tool class that enacts the specific behavior.

This would drastically simplify the swapping shenaningans, as we only have to worry about what the editor ui has as it's 'Active Tool', and change that via a simple function call, it changes the tool it's pointed at, and all interaction functions trickle down to the tool for handling, such as your mouse clicks and the like.

This would make things WAY easier to add new tools and just drop things in, and just alltogether make things more self contained per-tool.

Another though I had, which would tie to the above, is build in different pointer modes.

Ie, regular mouse pointer(like your regular world editor mode), paint brush pointer(like the terrain editors or forest), etc.

So rather than needing an entire render override for the editor view just to enable stuff like the paint mode, you'd set the pointer mode to radial brush mode, set the radius and an option for grid-alignment for stuff like terrain), and the masks for the raycasts it fires out when rendering and also painting.

This way the tool can just worry about the results of the interaction, rather than micromanaging the interaction itself.

Then, obviously, the tools can just have script functions out the wazoo for hooks into the editor suite itself.

Does that approach sound like it'd make more sense?

Well, effectively, that's what the grid shows. It shows spheres with 0-1 roughness and metalness, one for each axis.

Same idea as this display:

http://i.imgur.com/Gt7VoVn.jpg

it should generate a console.log file in the same directory as the exe.

@Chelaru

Can you clarify what looks WIP? Do you not like the demo model? Or does the PBR look incorrect to you?

Yeah, I did pull that to test, there was some issue with the terrain texture fix they added, so I'll try and get that sorted out and we can get it merged in.

As for the edge issue, I did create a new map with 2 terrains side by side, both flat, and plunked the cheeta right on the seam, and all 4 wheels correctly matched to the ground(which uses raycasts)

So the best-guess so far is that - going off your mention it seems to be a problem when the opposite sides of the terrain block have differeing heights - the terrain is trying to have wrapping occur, even if that setting is off. If that's the case, that should narrow things down quite a bit.

I'd seen a few other people comment about casts and stuff breaking down on terrain edges, but hadn't had much luck with replication. I take it it happens with every block seam?

Do you have a log file from when it crashes from loading a model?

Can you post some screenshots? Bit easier to have an idea of graphical problems that way.

Are you familiar with the entity/component stuff I've been working on?

The E/C stuff has a redone collision scheme, making it way easier to set up collisions on stuff in whatever way the user wants.

T3D's gotten a lot of work done on it to make it use SDL2 for most of the platform stuffs. It may be worth checking that out and seeing if that'd be more prudent than trying to maintain the platform layers manually.

If all the kinks with the platformSDL stuff get worked out, then conceptually you'd only need to maintain tidbits of gluecode, rather than entire platform layers.

Dynamically, as in during the game running? So like leg IK?

In that case, the ShapeConstructor methods wouldn't work. That's for configuring the shape to your needs before spawning. Once it's created, the ShapeConstructor methods don't affect it outside of reloading.

To manually change bone positions in code during runtime, you'd need to look into the animation code in ShapeInstance, and the HandsOff mask for bones. That lets the bones be animated by code rather than animation sequences.

Feel free to copy the rig once that dude is ready to go :)

I needed a baseline player model and rig for prototyping, and eventually to be used for the characters in my games.

So I rigged up a simple Low-poly dude to a simple skeleton, with some nice controls to make it easier to utilize effectively.

http://ghc-games.com/public/RedGuy.png

Figured I'd toss him up here, and see if anyone had a use for it. As said, it's my baseline rig, so I plan to use it in general, but if others have an interest, I could take suggestions/ideas for some improvements.

Who knows, maybe given how light Red Guy is comparatively(and that there'd be source art), we could make him the default player model in the templates :P

Link to him is here

KorkScript, duh.