saindd

The problem is that the terrain ends up being really small at 1 meter per pixel, versus a 2048x2048 heightmap.

2 meters per pixel, 5000 height scale. 2048x2048 maps, PNG 16.

Maybe the color range i'm using in the splatmap might be the cause?

Well, here's a screenshot straight out of the docs:

http://docs.garagegames.com/torque-3d/official/content/documentation/World%20Editor/Editors/images/PathPaintAfter.jpg

That only changes the detail texture size and how it's distributed. I'm talking about the terrible resolution between the blends there, look at the area between dark and bright textures. No matter which brush i use to try to "cleanup" after the splatmap import, it's just painting some ugly polys.

I'm importing a 2048x2048 splatmap texture from World Machine when creating my terrain and associating terrain materials with each channel from the splatmap. It works fine, but the resolution of the painted layers is very very crappy. For example:

http://i.imgur.com/kdL3qNI.png

Is this related to the brush resolution in Torque? How can i tweak this?

There's a lot of learning material for Torque:

http://www.garagegames.com/products/torque-3d/fps#/1-setup/1

http://www.amazon.com/Torque-3D-Game-Development-Cookbook/dp/1849693544

https://github.com/lukaspj/Torque3D-Tutorials

But that kinda defeats the purpose of using the engine per-se. The pros are the editors and the abstractions.

Why do you say using materials is not efficient?

That's simply not true:

https://developer.valvesoftware.com/wiki/HDR_Skybox_Creation

What i actually meant is: if i use .hdr or .exr as a skybox, will Torque use that HDR information into the pipeline?

If you write your own loader, yes. It would be wiser to just integrate Assimp with T3D, actually. Then, you gain the benefit of using MD3 and MD2, along with a shitload of other formats. And you can help contribute to Torque's ecosystem.

I would write a custom BSP loader, though. You're going to have a bad time with collision if you end up using ASE/OBJ from q3map2. It's not very difficult:

http://www.flipcode.com/archives/Simple_Quake3_BSP_Loader.shtml

Dealing with the Torque API will be the real trouble.

That's gamedev. A breakfast full of frustration and deception. And we love it.

q3map2 can compile to ASE, which you can convert to OBJ using pretty much any tool out there.

I've noticed that in the editor, the particles only support simple textures. Apparently, there's no support for materials, so i can't use normal-mapped bullet-holes or other effects with different specularity/normals, etc. Not even animated particles.

Is there a way to circumvent this?

Clothing sucks. But, even if it was good, manually doing the clothes with Blender's sculpting tools seems like a better option. Or Marvelous Designer.

MakeHuman -> Blender -> DAE and that's pretty much it. Of course, assuming you rewrote parts of the character class to match the new bone structure. You'll eventually have to do that, since the current code is unusable. =\

Why don't you guys just use MakeHuman? http://www.makehuman.org/

Free, open-source software and art. And the art can be automatically rigged, in a format compatible with Blender's.

Why there is no documentation for that class here (http://docs.garagegames.com/torque-3d/reference/annotated.html)?

Since i have limited animation skills, i'm trying to create more with less. I've decided to take David Rosen's approach to animation, but i'm starting with something really simple and not that complex. Basically, i've made 3 keyframes, with the character posed in what is going to be the running animation. I have the keyframes imported successfully in Torque, but i have no idea how to blend between then during the run state. The current character code only plays an existing animation sequence, and i'm trying to build a sequence in runtime, based on the poses i have set.

I've studied the Blends feature, but it seems like a solution to blend between animation sequences, so the player can smoothly go from Jumping to Running, for example. Could it be used for this purpose? Or maybe that's a task for the Threads feature?

Exactly what i was looking for! Thank you, sir.

Just edges. I'm actually planning to write an animated material and use that, instead of a static texture.

Any ideas when the Pacific Demo will be released? :)

There is a decent hitbox system already: http://www.garagegames.com/community/resource/view/6538/

You can pretty much have any hitbox structure you want. I prefer Valve's approach, which is pretty nice. My problems is with player movement and interaction with the physics world. A box is a terrible way to detect collisions with other meshes and the terrain.

@LukasPJ, the abstraction layer does not allow me to call and interact with Bullet directly, therefore, i'm not able to fully use it's power. I guess i'll endup removing all the code for PhysX and the default Torque Physics.

If the bounding box is dropped, only the player class code has to be changed? Or is this a very deep feature of T3D?

Also, how can i set Bullet as the defacto-standard? Without any abstraction? I find Torque Physics very limiting. I can't work with joints, apply limits, use ragdolls or anything.

The bounding box behavior is terrible. Does the Torque Physics engine support capsule colliders?