### Work Blog - JeffR

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm

Yeah, part of this would involve getting collada export fixed.

#### Re: Work Blog - JeffR

SqHd
Posts: 55
Joined: Tue Apr 14, 2015 5:02 am
Nice! Can't wait! Thanks for adding such a cool feature to T3D!

#### Re: Work Blog - JeffR

chriscalef
Posts: 381
Joined: Mon Feb 09, 2015 7:48 pm
Hey @ JeffR, I thought I'd check out your EC_Experimental2 build, but I'm having some compile trouble. Does the following set of errors make any sense to you?

Code: Select all

1>F:/T3D/Areloch/Torque3D/Engine/source/console/dynamicTypes.h(246): error C2838: '_smTypeId' : illegal qualified name in member declaration 1> F:\T3D\Areloch\Torque3D\Engine\source\T3D\assets\MaterialAsset.cpp(241) : see reference to function template instantiation 'S32 TYPEID<MaterialAsset::AnimType>(void)' being compiled 1>F:/T3D/Areloch/Torque3D/Engine/source/console/dynamicTypes.h(246): error C2065: '_smTypeId' : undeclared identifier 
There are a few more similar errors for the other uses of the TYPEID template, all of them involving calls like this:

Code: Select all

 addField("animFlags", TYPEID< AnimType >(), Offset(mAnimFlags, MaterialAsset), MAX_STAGES, "The types of animation to play on this material."); 
This is using VC2010 (I know, I know...)

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm

Ah, whoops, yeah, those are still WIP files.

If you remove them from the project, everything else should work as expected. The real push'll be much more cleaned up

#### Re: Work Blog - JeffR

Julius
Posts: 28
Joined: Sun Apr 05, 2015 6:45 pm
That brush tool sounds great, really looking forward to it as it would complement the awesome terrain and nature editing features already in Torque3D.

Please keep a working "undo" with a few steps (3-5 at least) feature in mind, and as you say: snap to grid is a must.

Is there anything to keep in mind when linking to physics objects? Like constructing non-destructable concrete walls with the brush tool and then placing pre-made CGI-sheet roof panel models on top that can be blown off by a grenade?

As it will be mostly used for simple stuff that integrates with the terrain (side walk concrete etc.) any idea to have a texture blend option to have a smooth transition from the underlaying terrain texture to simulate dirt or moss? Generally a blend option between different tiling textures would be nice.

Simple cut&past: select part of the geometry of the brush tool and use ctrl+c and ctrl+v to duplicate it so that it is easy to build structures with replicating parts.

Related to this, maybe there can be a sort of grouping option? I understand that there are different .brush files that probably will represent different "meshes" in a scene, but inside such a mesh, can there be customizable sub-sections that can be easily selected from a drop-down list and then edited/deleted/duplicated etc.?

Will it be possible to cut into the terrain with a brush-tool structure? To make a cave or entrance to a dungeon or such? Should probably include some sort of easy to place VIS culling.

What about placing non-solid "brushes" of water, volumetric fog etc. to fill in a cavity made by solid brushes?

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm

Good suggestions!

1) Yep, undo functionality will be retained.

2) That'd just be regular Physics Objects, yeah? The BrushObject is a sceneObject like any other, so you'd be able to build out a level framework with it and then add in other objects over it.

3) This is something I've thought on, but I'm unsure of the best way to approach it. It uses regular materials for it's surface rendering, so having blended materials would necessitate vert color blending between materials. Definitely would be worth having, but a more complicated to get implemented.

4) Cut-n-Paste is planned, both for brushes, and a face's UV info, so material, offset, scale, rotation, etc. That way you can easily get a wall to be cohesively textured even if it's several separate brushes.

5) Yup, selection groups is planned.

6) This is actually a really good idea. It'd be a nice way to figure out what terrain tris to flag as 'cut'. I don't think it'd be too hard to implement it where it'll find all terrain verts inside the cutting brush and flag them to 'empty'.

7) I do want to have a way to easily create interop between the brush editing and other similar, but different classes, like the zones, occluders, triggers, etc. However, water is kinda already handled with the water block.

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm

Alright, so, nearly done on the initial build of the New Template.

The remaining issues is a issue with the slider rendering I need to fix, and finish out the Join Server menu, but everything else seems to work as expected. Hoping to have that wrapped tomorrow for people to nab and start hammering on to find the issues I missed.

Would've gotten it done tonight, but i had to retool how I was doing the sliders because I was botching the order-of-operations for their setup, meaning they were had their values set before their range was. Took me a bit to track that down, so I didn't get a wrap on the other stuff.

But as said, shooting for tomorrow night to have this done and ready for initial poking and proding

For eye candy, behold! Camera settings(the zoom sensitivity does actually work, too! It should be a useful example for people that want finer control on scoped weapons or the like)

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm

With the new template in wrapup phases(We just gotta get deferred merged in and the new template updated to that and we're pretty much gold), I took some time to muss with the e/c stuff more.

The basic spread of components is very nearly done, so I've started doing little gameplay prototpying bits purely in script to see what I can get out of it, what needs exposing to script and what bugs crop up in a real usage case.

So, I implemented a third person shooter-type character with wall jumping.

Here's a video showing walljumping:

There's a bug where I don't properly validate the ground surface, so it's possible to jump mid-air if you jump straight up, which is why I did the weird double-jump. Easy to fix

But as the video shows, you jump at a wall and if you jump again, you turn away from it and jump off the wall. You can even chain your jumps, wall to wall. Ideally in a game, you'd actually gain a little bit of height to the jump, but it shows the idea well enough.

And a video to show the basic handling of the Third Person Shooter side:

As you can see, player turns to face the move direction when in the regular pulled-back view which has an orbit camera.
When you aim, it brings the camera into an over-the-shoulder view(I hadn't set an offset so it just sits right behind the player atm, being blocked by their fat head), the controls switch back to your shooter configuration, forward/back and strafing based on where you're looking.

Also crouch is in there, which permutes the speed.

All pretty standard stuff.

The script code to make it happen:
function ThirdPersonPlayerObject::onAdd(%this)
{
%this.turnRate = 0.3;

%this.phys = %this.getComponent("PlayerControllerComponent");
%this.collision = %this.getComponent("CollisionComponent");
%this.cam = %this.getComponent("CameraComponent");
%this.camArm = %this.getComponent("CameraOrbiterComponent");
%this.animation = %this.getComponent("AnimationComponent");
%this.stateMachine = %this.getComponent("StateMachineComponent");

%this.stateMachine.forwardVector = 0;

%this.crouch = false;

%this.crouchSpeedMod = 0.5;
}

function ThirdPersonPlayerObject::onRemove(%this)
{

}

function ThirdPersonPlayerObject::moveVectorEvent(%this)
{
%moveVector = %this.getMoveVector();

// forward of the camera on the x-z plane
%cameraForward = %this.cam.getForwardVector();

%cameraRight = %this.cam.getRightVector();

%moveVec = VectorAdd(VectorScale(%cameraRight, %moveVector.x), VectorScale(%cameraForward, %moveVector.y));

if(%this.aiming)
{
%forMove = "0 0 0";

if(%moveVector.x != 0)
{
%this.phys.inputVelocity.x = %moveVector.x * 10;
}
else
{
%this.phys.inputVelocity.x = 0;
}

if(%moveVector.y != 0)
{

%this.phys.inputVelocity.y = %moveVector.y * 10;
}
else
{
%this.phys.inputVelocity.y = 0;
}
}
else
{
if(%moveVec.x == 0 && %moveVec.y == 0)
{
%this.phys.inputVelocity = "0 0 0";
%this.stateMachine.forwardVector = 0;
}
else
{
%moveVec.z = 0;

%curForVec = %this.getForwardVector();

%newForVec = VectorLerp(%curForVec, %moveVec, %this.turnRate);

%this.setForwardVector(%newForVec);

if(%this.crouch)
%this.phys.inputVelocity.y = 10 * %this.crouchSpeedMod;
else
%this.phys.inputVelocity.y = 10;

%this.stateMachine.forwardVector = 1;
}
}
}

function ThirdPersonPlayerObject::moveYawEvent(%this)
{
%moveRotation = %this.getMoveRotation();

%camOrb = %this.getComponent("CameraOrbiterComponent");

if(%this.aiming)
{
%this.rotation.z += %moveRotation.z * 10;
}

%camOrb.rotation.z += %moveRotation.z * 10;
}

function ThirdPersonPlayerObject::movePitchEvent(%this)
{
%moveRotation = %this.getMoveRotation();

%camOrb = %this.getComponent("CameraOrbiterComponent");

%camOrb.rotation.x += %moveRotation.x * 10;
}

function ThirdPersonPlayerObject::moveRollEvent(%this){}

function ThirdPersonPlayerObject::moveTriggerEvent(%this, %triggerNum, %triggerValue)
{
if(%triggerNum == 3 && %triggerValue == true)
{
//Doing the flashlight thing
if(%this.getObject(0).isEnabled)
%this.getObject(0).setLightEnabled(false);
else
%this.getObject(0).setLightEnabled(true);
}
else if(%triggerNum == 2 && %triggerValue == true)
{
//get our best collision assuming up is 0 0 1
%collisionAngle = %this.collision.getBestCollisionAngle("0 0 1");

if(%collisionAngle >= 80)
{
%surfaceNormal = %this.collision.getCollisionNormal(0);
%jumpVector = VectorScale(%surfaceNormal, 200);
echo("Jump surface Angle is at: " @ %surfaceNormal);

%this.phys.applyImpulse(%this.position, %jumpVector);
%this.setForwardVector(%jumpVector);
}
else
%this.phys.applyImpulse(%this.position, "0 0 300");
}
else if(%triggerNum == 4)
{
%this.crouch = %triggerValue;
}
else if(%triggerNum == 1)
{
%this.aiming = %triggerValue;

if(%this.aiming)
{
%this.rotation.z = %this.cam.rotationOffset.z;
%this.camArm.orbitDistance = 1.5;
}
else
{
%this.camArm.orbitDistance = 5;
}
}
}

function ThirdPersonPlayerObject::onCollisionEvent(%this, %colObject, %colNormal, %colPoint, %colMatID, %velocity)
{
if(!%this.phys.isContacted())
echo(%this @ " collided with " @ %colObject);
}

function ThirdPersonPlayerObject::processTick(%this)
{
%moveVec = %this.getMoveVector();
%bestFit = "";

if(%this.crouch)
{
if(%moveVec.x != 0 || %moveVec.y != 0)
%bestFit = "Crouch_Forward";
else
%bestFit = "Crouch_Root";
}
else
{
if(%moveVec.x != 0 || %moveVec.y != 0)
%bestFit = "Run";
else
%bestFit = "Root";
}

}
As you can see, with the e/c setup, it doesn't take a whole heck of a lot to get a good bit of gameplay mechanical stuff going, and in script to boot.

The end result would be to let you implement just about anything gameplay-wise in script for fast development time, and then as needed later port it up into the engine for efficiency.

For the release, I'm looking at having a few test/example cases for people to play, such as a 3d platformer with walljumping and stuff, like Mario 64, a First Person collectathon, a third person shooter, and a fixed-camera tank controller, like the first few Resident Evil games.

That should give a good starting spread of example cases on usage, and the plan would be to add more examples/prototype kits for people to use/build on easily that could be dropped in.

#### Re: Work Blog - JeffR

TheDushan
Posts: 2
Joined: Mon Feb 23, 2015 9:45 pm

JeffR

If I may ask what is the status of "Node and Web Graph Guis"?

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 932
Joined: Tue Feb 03, 2015 9:49 pm

Hey everyone!

So I had a week of vacation and used that time to work on stuff including a march towards a gameplay prototype.

The main reason was, it's hard to know what parts need work if they aren't being used, so even if I'm fairly confident in my entity/component work, it's hard to be sure without giving it a run-through.

So, I decided during my week off of work to take some time and really jam on stuff particular to a gameplay prototype goal. I'd settled on a thief-like setup, because we need more games like Thief in the world, and a lot of the stuff written for that would be shareable on other projects.

The main goal of this little deal was to
a) flesh out the weak parts in the pipeline, and discover/fix bugs(which I found several and fixed some of them, so those will be getting PR'd) and
b) implement all gameplay code purely in script. The only changes made engine-wise were bugfixes and expanding general interface stuff(such as callbacks and console methods). Outside the core components like collision, rendering, etc all actual gameplay components and logic were to be implemented in script.

The reason for b is to ensure the engine is easy to rapidly prototype in, and ensure there aren't any sort of crutches in the engine-side that you'd have to rely on to get something done for gameplay mechanics. Obviously in a production project, you'd no doubt port stuff up into the engine for performance reasons, but you should be able to at least prototype out in script all your gameplay stuffs before needing to crack open the engine for optimizations.

So where's it at? There's a few bits that aren't shown in this video, but it covers a good breadth of what I worked on:

A big bit of the time was spent working on the Asset Browser and pipeline parts. I a big complain people have had is that the pipeline for Torque isn't so hot, so this is going to be a big step forward on that. Obviously, it's not all the way there, but compared to the few screens I've posted from my prior work with the asset browser, which was closer to a mock-up than a functioning tool, this is a big improvement.

As you can see from the video, the first thing is(and It's hard to see because arrows aren't all that big) is I shoot some arrows into a wall and then can walk over and pluck them back out.

This is accomplished by having a GameObject: Arrow Projectile.You can see the components it has here:

As you can see we obviously have our mesh component to render the mesh, but we also have a collision, projectile, item and interactable component.

The projectile component(written in script, of course) lets the entity act like a projectile, moving forward at a given velocity and doing a raycast for a collision, in which it stops where it hit - because arrows stick in walls and stuff.

Being able to recover arrows is important, so I used the collision component to let the arrow be hit by raycasts itself, and then drafted an item and interactable components. The item component currently doesn't do much as the inventory component for the player is still WIP, but it'll track item data of the object, such as it's name, description, icon, etc, as well as max inventory count that can be carried of that type. The interactable component is the interesting one, I think.

On a basic level, it just lets the entity be interacted with by virtue of the player game object, which has a interact component. This component shoots out raycasts at each tick, and if it its an entity, we check if that entity has an interactable component. This lets us know that that's an object we can interact with in some way. The component itself is actualy really simple, but implements a nifty trick. When the interact component on the player confirms it has an entity with an interactable component, it does a function call so the interactable shoots off a commandToClient to get the pop-up prompt about interacting on screen.

Then, when the player hits our use button, the player object(knowing we have a valid interactable object) calls it's "use" command on the interactable component, which looks like this:
function InteractableComponent::use(%this, %user)
{
%this.owner.notify("onInteracted", %user);
}
Notify() is a function I added, with a few more pending, that basically acts similar to a signal trigger. It tells the entity to call a certain function on all components under it(that have it, of course).

In this case, this notifies our item component it's been interacted with, and thus the arrow is grabbed and will be added to our inventory.

A similar setup is seen with the light on the table, only that is a separate CandleItem component, which has an associated point light it keeps tabs on. When onInteracted is called, the light is disabled and poof, suddenly you can snuff out candles.

From there, we open up the editor to scope out the Asset Browser. As you can see, the tree view on the left separates out assets by the module package they're associated with and then further by the asset type: Component, Game Object, Image and Shape are the types currently, though obviously going forward we'll be looking at materials, animations, sounds, etc.

It's not fully functioning yet, but you get an example of the right-click pop-up menu letting you edit an asset via the pop-up inspector. I also plan to have other options in the popup, including type-specific ones, so game objects and component assets can have a "open script in Torsion" option, etc.

We also get to see the new importing process. Before, you had to drop your file in the directory, then navigate to it, open it in the shape editor or spawn it to kick off the cached dts generation process, then make sure the materials were named correct and pointed to the right image files, and if the images were in a different directory it'd get all weird there, etc, etc.

With this, you drag-n-drop onto the asset browser window, it kicks off the import process, letting you know what assets you're importing, and letting you pick(or create) a relevent module. Then it runs through, copies the files into the respective directories, generates the cached.dts files for shapes using default settings and the assets then show up in the asset browser and can be used.

Obvious improvements from here is being able to move assets around, being able to tweak the cached.dts generation process, and controlling on a project-level where assets are dumped, as not everyone structures their projects the same way.

To wrap up the broad features, the new button lets you create a new asset, of course(currently only a component asset can be made this way)

And here's how you can make a Game Object when you're happy with the configuration of your entity + components + child objects:

In both cases, the relevent asset file is created, as well as a taml file for the game object so it can be easily spawned as needed, and in both cases a script file is generated and pre-populated with common functions to get you on your way implementing stuff.

Obviously, the idea is to drastically cut-down on busywork time and get straight to implementing gameplay or using assets. Quite a bit of work to be done, but it's getting there! This approach will be ready for 4.0.

Also, I think I'll keep on this thief-like a little while longer, if at minimum because it's a good tester of systems, but also because as said, we need more thief-like games.

As always, any questions or suggestions are welcome!

#### Who is online

Users browsing this forum: No registered users and 2 guests