JeffR

Not sure about intercepting, but an example would be like, suppose you had a weapon with a bunch of mounted attachments that you want to do something when you reload(have little dodads move, etc)

So each of those would have a "reload" animation. Then you'd use the smartPlayThread(%myGun,"reload",true); to tell the gun to play the reload animation, but it would also iterate over all the mounted objects and tell them to play their reload animations as well.

This would let you have all your attachments do their little dodad animations upon the gun being reloaded, as per the example.

Hopefully that explains the idea. If not, is there a particular scenario you're thinking of?

Just pushed RC2, which has various improvements and fixes. It can be nabbed here.

In T3D the ground cover does billboarding which I find does not look great when close to the player. In BFBC2 they seem to use a 2D ground cover which does not billboard but is just fixed at some random rotation

Would it not be a good feature to allow a settable radius around the player / camera where the ground cover is just fixed at random rotations and beyond that it billboards?

I've actually considered that very thing. Sounds like quite a few of you people want it as well. Guess that'll have to get put on the list for reals then :P

It's a good middleground between the cheapness of billboards and the not-weird looking-ness of 3d meshes, so I'd say it's a good compromise.

Thanks Azaezel.

I am trying to do this without modding the c++.

I changed my above code to use a StaticShapeData object and I see it suffers with the same problem as the Turret. It does not stay in sync with the moving vehicle.

This is so frustrating. What do people do with this engine?? Wait let me guess.... the change the c++ to make it work :(

@JeffR - does version 4 sort this stuff out or does it just continue with more of the same?

Yeah, the entities are being intended to be very flexible, especially with the mounting. I'll have a look at the static shape mounting bit, it's not as flexible as it should be, but it definitely should at least keep up with the mount object. It sounds like the interpolation isn't handling it correctly as is, which means it's likely a bug.

With 4.0, the general ethos is going to be more of a "You shouldn't have to use the source unless you're optimizing for performance, or crazy specialized stuff, but general gameplay shouldn't require source changes. Source is there to make things shiney and fancy, not to get the game running".

I'll have to chuck some buxx at it when I get home!

Andrew had started implementing assimp but had issues with getting the animation portion working a while back.

I took a look at it myself because assimp support is on the docket for 4.0, and had integrated it into the ShapeAsset for loading. Got mesh loading fine and had been looking into the animation side(got it mostly figured out, but not 100% done).

I'll get the code I had for that and toss it into a branch for you if you wanted to poke at it. If we get animation loading sorted, it's mostly done. The odd part comes from how the different formats store their bone transform tweens.

The first thing, is I'd point out that ShapeBaseImage is primarily intended for use as mounted weapons.

If you were trying to mount "real" objects, such that may have collisions or the like, you'd want to use a different class, such as ShapeBase, or the like.

So for example, you have here:

https://github.com/GarageGames/Torque3D/blob/7bba3ee2de610c2757bc70eba10db869bab72a85/Templates/Full/game/scripts/server/vehicle.cs#L98

Which mounts the player to the vehicle at a given node slot.

For your traincars, you'd Shapebase or the like for your cars, and mount them like the above call. Then as needed set their mountPos and mountRot fields to tweak their position(assuming you don't have a special node to mount them to specifically). These are added to the parent's transform.

This way, when your vehicle moves, they will move with it.

The compilation issues with libCollada, which i got past after making some minor fixes. Also, the terrain in OpenGL seems very unstable. The character falls from it in certain areas (can't give more information right now, i'm trying to find a pattern in order to report this) and there are seams in the textures whenever you use normal or parallax mapping.

There are also random crashes with large terrains, but i also wasn't able to find a pattern yet. Are there any other Linux users out there? Maybe we can help by debugging together and sharing reports :geek:

Some of those aren't really OpenGL, persay, but yeah, definitely need to be addressed.

If you and anyone else running Linux have more details, like logs, or video/screenshots of stuff happening, then we can get all over that. It's hard to debug stuff we can't reproduce, after all :)

I've noticed many bugs in the 3.9 OpenGL implementation that were reported since 3.7. So, it doesn't seem that much was done on that part. Is there a changelog of the fixes made to OpenGL?

Were you just noting the outstanding issues list(which does need some pruning, now), or have you noticed some issues in particular when testing?

When I pull, generate new projects and compile the development branch in VS2015, I get:

Severity Code Description Project File Line Suppression State

Error C1083 Cannot open include file: 'nfd.h': No such file or directory Full DLL d:\gamedev\torque3d-hobby\torque3d - 2\engine\source\platform\nativedialogs\filedialog.cpp 32

 

As well as:

15>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(936,5): warning MSB8027: Two or more files with the name of fileDialog.cpp will produce outputs to the same location. This can lead to an incorrect build result. The files involved are ..\..\..\..\..\Engine\source\platform\nativeDialogs\fileDialog.cpp, ..\..\..\..\..\Engine\source\platformWin32\nativeDialogs\fileDialog.cpp.

How'd you generate the project? Sounds like it didn't filter the files correctly, there.

So this version is the last version to support DX9, right?

Yep!

Where i can find more info about the ECS implementation? Is OpenGL in sync with DX11 features?

I'll start working on some wiki pages/tutorial bits, but the first thing you need to do if you want to start playing with it is activate it in cmake and compile it in.

You can do that by turning on the advanced flag TORQUE_EXPERIMENTAL_EC, generating and rebuilding. That'll build the engine stuffs with it included, and if you run the install project, it'll install the associated files/tool bits for the full template as well.

From there, when you go into a level, you can find the Entity class type to spawn it under the Level folder in the creator. If you select an entity, there'll be a drop-down that lists available components that can be added to the entity. Any components on the entity will be show up in a special sub-item in the Scene heirarchy tree called 'Components'. In there you can select the components, modify their properties, etc.

You can also save a Entity to be a 'game object', which is pretty much a prefab with an associated script, by right-clicking on an entity in the scene view and clicking the associated command. Any Game Objects will show up in the GameObjects folder in the scripted tab in the creator.

This way, you can build up, say, a player object(the included example GameObject is an example of how a player object for a third person game may be configured), save it as a Game Object with a unique name, and readily spawn it via the editor, or the console command spawnGameObject(%gameObjectName, %addToMissionGroup);

Once it's been created via the editor, it'll have a script generated alongside it you can add code to affect the game object as a whole, or modify/create new components for particular behavior.

As for the DX/GL, az answered that one above.

Stuff like this is always nifty. I'm looking forward to progress on this :D

Hey everyone!

After a bit of a delay off the original estimate(due to trying to squash some bugs that kept on cropped up that we wanted fixed), the release candidate is finally here!

You can grab it from the github page for it, here. Source code, Windows and Linux binaries for the release are there.

Several new things are in play, like the proper deferred renderer, DX11 support, the experimental Entity/Component stuff, proper file dialogs on Linux and a multitude of other fixes, improvements and additions.

The release candidate cycle will probably run until the end of the month so we can make sure to really hammer in any bugs that may have squeaked through the cracks unless everything goes really smoothly, and then the full release and a breakdown of plans for 4.0! In the meantime, we'll keep an eye out on any other bugs, and I'll wrap up the port of the old GG demos to go out with 3.9 on release.

You should be able to put the lightmaps that you generate yourself from Blender into the same material lightmap slots. There's no support currently for generating UV2's or baking lightmaps directly inside of Torque3D. We had planned once on integrating pureLIGHT directly into the Torque3D editor but those talks fell apart years ago.

I don't remember all the details of how the Torque3D lightmapping works, its been many years since I last looked at it. There were flags to indicate which lights were included in the lightmaps to avoid double-lighting meshes. I don't know if much has changed since then.

I did experiment once with changing the way Torque3D internally stores its lightmaps. It wasn't too hard to make them assignable per mesh and point them at a part of a larger lightmap atlas instead of a separate texture like it currently requires. I believe I still have the code for doing that kicking around on my computer, though that would have been for a version of Torque3D many years old by now.

If you've still got the code, I wouldn't at all mind having a gander at it. I've been mulling on getting baked lighting back into the fold for 4.0-ish, so anything that'd jumpstart on that would be incredibly useful.

Yeah, I think linux just has much stricter handling for 32/64 bits.

I'd read somewhere you just have to have 2 builds and use the appropriate version based on which archetecture you're running. I'll look into it some to see if there's a sidestep.

As for the SDL static and gtk stuff, can you test this?

https://github.com/GarageGames/Torque3D/pull/1627

That statics SDL, and also hooks the file dialogue usage to TORQUE_PLAYER. If you flip on the TORQUE_PLAYER flag, which implies it's intended for end-user players and thus the tools won't be needed, it'll basically drop the file dialog stuff from the project, so that you don't need to install gtk to simply run the game if you're an end-user.

Looked into this, and the issue is that the Vehicle class doesn't actually hook into the physics plugins so they exist in the physics sim. As such objects that operate via the sim don't know it exists and can't collide with it.

Fortunately, Timmy's got some code that registers a physics body for the vehicle which should remedy that, and I'll test plugging that in tomorrow/PRing it if it works.

Yeah, GTK is used for the native file dialogs in Linux to render them.

For release projects, I'm adding it in so if you disable the TORQUE_TOOLS flag in cmake, it'll not include the file dialogs(since those are only used in the tools anyways) so that endusers don't need to make sure gtk is installed.

For anyone wanting to use the tools with the file dialogs though, you need to have gtk installed on Linux. I thought I updated the wiki page, but I may not have.

Anywho, getting the gtk package with 'pkg-config --cflags --libs gtk+-3.0' should get it installed for you. I'll make sure the docs are updated and get the tweak to cmake pushed tonight(as well as making static SDL the default :) )

Nah, you're fine, they can get used kinda interchangeably sometimes.

Are you using any of the physics plugins(bullet/physics) or is it just the stock Torque physics?

When you say mounting, do you mean the player mounting to the vehicle so you can drive it? Or are you just trying to attach other objects onto it, like particle effects?

The biggest issue with morph targets is that lots of art pipelines don't support them at all anymore.

Assimp doesn't support it, for example.

Torque had some nominal support for them, but I haven't personally tried it myself.

Most current games I've looked into for this sort of thing seem to have largely shifted to bones, with bone scaling and clever rigging to change the character shape. For example the Sims 3 and 4 do this.

For a basic breakdown in how both approaches would work:

For morph targets, you would create a series of shape keys, or separate models with the different adjustments you'd want(such as, say, the nose being bigger). You'd export these out and load them into the engine and basically store the vert positions as a separate type of animation rather than bones which stores the positions of the verts at their modified placement.

When you'd go to blend on the shape key animation, you'd handle those separately from bone animations by having your 0-1 value dictate how blended between the 'unchanged' and 'totally changed' you want for that shape animation. You'd do that for each of the morph targets to get a final blended position.

I think the main reason this has phased out is with the shift to instanced meshes. Instancing require the verts to be in the same position, so in order to morph targets on TOP of hardware skinning the bone transforms, means you'd not only be passing up the transforms for all the bones to affect the model, but you'd also have to pass along vert permutation info. You can potentially chew up a good bit of bandwidth hocking all that data around and it also complicates the shaders some.

Not impossible, but less than ideal, which again may be why it's less common now.

The other approach, which seems to be the main way these days, is using bone positions and scaling. This method doesn't require any special pipeline handling, and doesn't change anything about the rendering/shaders in regards to instancing/hardware skinning, which is most likely why it's favored.

The basic idea with this is that you would, when rigging your character as normal, add in additional bones that are children of your regular rig bones. Various parts of the model are skinned to those bones, so they animate normally, but when you adjust their position, or their scale, it influences the look of the geometry of the model.

For example, you could have a bone in the nose, and if you move it up or down via a simple offset value(or a blended animation), this moves the nose up and down on the face. If you scale the bone, the nose gets bigger or smaller, etc.

I don't know at a glance what Mixamo Fuse uses, since they don't need to do optimizations for realtime rendering while editing the character, it's possible they went with morphs, but if they did end up using the bones approach, you can see if those bones are exported along with the model. If they are, you should be able to fairly readily utilize them to have similar customization.

If you're rolling your own character from scratch, you'd naturally need to add those bones yourself. Once the bones exist and are rigged to the mesh though, adjusting them via blended anims or code is fairly straightforward.

Yep, the plan is for them to go out when 3.9 is fully released. We're wrapping up any issues that really annoy us and then 3.9 will be put up as a Release Candidate, and I plan to take that time to put a wrap on the demos.

That said, the pacific demo content has been out for a while now, and can be grabbed off the wiki, here:

http://wiki.torque3d.org/main:downloads

:)

I would also note that while @rlranft is right that any changes the source code will necessitate SOME kind of recompile, you can also download the precompiled binaries from the last major release via the wiki, here: http://wiki.torque3d.org/main:downloads#toc4

That'll have the exe already and you can using the scripts and gui/world editors to work on stuf/test stuff out before needing to worry about diving into the source code.

Given that the internationalization stuff seems to mostly operate out of the script/gui editor side, the precompiled binaries should be sufficient to at least test things out.

Wow, he does NOT look happy.

Oh man, this thing is incredible. Thank you so much for the find.

Paul:

Are you able to compile the current devhead without any unresolved externals? Not sure if you're running into DX11, or the VR stuff. May help to take a step back and affirm that devhead compiles and runs well, then we can see about walking through the merge of the WIP VR branch.

And as mango said, if you can get a copy of the errors/unresolved externals, that'd be a major help.