Tiel

I don't think there's a property for ScatterSky that lets you render a bottom half to it. If you were to use the Skybox class instead, that does let you specify a cubemap and get a complete surrounding sky without the whitespace, but at the expense of the cool features scattersky has like the day/night cycle.

What you could do is hide it, which will help in other ways too (nothing's more jarring than running into the edge of the world!)

The first is elevation. If you make the terrain itself higher on the Z Axis, the corners of the scattersky become a lot less apparent from the ground.

http://imageshack.com/a/img922/5391/4tR62V.png

http://imageshack.com/a/img924/3849/muSwvR.png

Also in this level there is a lot of terrain variation (default Outpost.mis). If there are hills blocking the whitespace, not only do you hide it but you also have a legit reason to prevent people from going to the edges and looking out into the abyss. Outpost is pretty big, only a small part of it is playable, the rest is just window dressing so it looks and feels like you're in the middle of something. Window dressing.

http://imageshack.com/a/img923/695/LbGjRU.png

With intervening terrain, height, and designing the level in your favor, the last thing you can do to make it less obvious is adding fog to the level. I think even if you went to the edge of outpost you can barely see the black (or yellow I guess) just because it's fogged out and blends well.

http://imageshack.com/a/img924/7741/ZPRXh6.png

There's also a waterPlane, which extends forever and does a lot to obscure it. Not always practical though.

Honestly if you ask me your best bet is to design maps in a way that there's always something obscuring the blank space, like steep cliffs or mountains in the horizon, and raising your level enough that players can't see the edges of the umbrella from the highest point. Alternatively, Skybox is always an option if you want to sacrifice some options.

When telling a client.camera to orbitobject around a serverside object, it will work as expected. Perfect!

http://imageshack.com/a/img923/2739/LnrQvS.gif

However, upon

newtonMode=true;

While the camera will perform smoothly on a localclient connection,

http://imageshack.com/a/img923/2442/fRgrEO.gif

any clients attempting to connect through gameconnection means will have a positively jerky experience.

http://imageshack.com/a/img924/7886/3XSXhS.gif

The camera will function fine in newtonmode as long as it's not tracking a moving serverside object. I'm convinced it's a networking issue given the circumstances but I don't know how to go about fixing it.

Help pl0x?

PS: Running T3D 3.10

Hello!

I've read the article on the wiki regarding compiling a 64 bit build of T3D, but not entirely clear on a couple of items on this list.

Firstly,

"go into the DLL project, and remove the asm files from platform/ and math/. They are not currently compatible with a 64bit environment."

Does this mean functionality available in x86 on the TS side of things will not be in the finished product?

Secondly,

"Any additional plugins such as physics will need to have the appropriate 64-bit includes and libs as well."

So I've been told I'm not the smartest guy on the block :lol:

What I do gather is that there are libraries that certain addons rely on that are only present in the distributed version of T3D's source in their 32 bit form.

Plugins are the options available when doing the compilation in CMAKE? (Like Bullet, etc, memory's a bit foggy and away from computer for a couple of days)

So hypothetically if I weren't selecting any of those options I wouldn't have to worry about anything? I presume C++ resources available throughout the web would be in good working order *unless* they had includes in their code to the defunct libs?

Awesome, much obliged.

When you set up a multiplayer server, I understand there's a dissonance between what's on the server vs the client. Correct me if I'm wrong, but on connect, a client has objects in the game world 'ghosted' to them, is the word. Following that any game logic should be on the server.

Because if you do, say

function serverCmdassignproperty(%thing)
{
%thing.juice="tampa";
}

A client attempting to access %thing.juice without calling a server command will not be able to retrieve the string "yes" and Torque throws a warning, at least in my tests.

This seems safe enough...or is it? Are there any circumstances where a client would be able to get %thing.juice without invoking a commandtoserver? Is there anything that should be done further to ensure .juice stays out of the wrong hands?

Okay, that seemed to please it.

Although, if I might go offtopic, I've also been trying to get this guy to work: http://www.garagegames.com/community/forums/viewthread/107847

// If we're mounted to them, don't give them anything!  
   ShapeBase* obj = this;  
   while(obj->getObjectMount())  
      if((SceneObject*)obj->getObjectMount() == convex->getObject())  
         return;  
      else  
         obj = obj->getObjectMount();

This displeases the compiler:

error C2440: '=' : cannot convert from 'SceneObject *' to 'ShapeBase *'

What I'm trying to do is mount staticshapes to an AIPlayer but it sounds like the collision's immobilizing them.

A resource I'm trying to port has the lines

// projected point
	mPtScreen = mPtProj;
 
	// alignment offset
	mPtScreen += offsetAlign;
 
	// screen offset
	mPtScreen += mOffsetScreen;
 
	// setTrgPosition(mPtScreen);
	mBounds.point=mPtScreen;

Problem being mBounds is private as of a few years ago. I'm not even going to pretend I'm comfortable with C++, but from what I've gathered this last line is to set the position of the control via mBounds.point (which is the topleftcorner of a ctrl to the best of my knowledge, forgive my ignorance). So getExtent() or getBounds, the replacement for retrieving extents with mBounds, wouldn't exactly work here, as those are functions that return a value, not the other way around.

Getting to the point, is there a replacement for mBounds.point?

Thanks for your thoughts,

I was never able to get shapenameHUD working, it's reluctant to function when set up like so

What I'm working with is

http://imageshack.com/a/img924/6854/I6LWgT.png

I'm not certain it's possible to get similar results with shapeNameHUD - also there's a lot going on in the gamespace and not sure how to make the control discriminate objects.

I'm looking for a way to have a billboard always face the screen, not just the camera position in the world.

This is to put a kind of 3D text above certain objects-kinda like waypoints but editable (is there a term for this?). What I have now works well enough, just not supergood with the BBs presenting themselves at an angle to adjust to the camera.

I think the only alternative would be to have hidden textctrls on playgui and schedule them to update when a special object is in view, though that seems less than ideal.

Greatly appreciate any input here

Ah, yes, got it. I went ahead and just stripped all the art and a good deal of script files from full and put my own stuff in, good to go.

Though with DX11 enabled in the project @ CMAKE there are a few strange artifacts.

http://imageshack.com/a/img922/4065/52naUn.png

(this is a guiobjectview with a model of an earth like planet with normals and specular. Or it would be, anyway, heh)

Went into options, there's a handy dropdown to switch the GPU over to D3D11, but restarting yields

failed to compile shader: C:\Users\cocka\Desktop\Torque3D-development\My Projects\Void\Null\game\shaders\procedural\5004b9ce_P.hlsl(52,23): error X3086: the 'sampler2D' keyword is deprecated in strict mode; use 'SamplerState' instead

C:\Users\cocka\Desktop\Torque3D-development\Engine\source\gfx\D3D11\gfxD3D11Shader.cpp(924,0): {Fatal-ISV} - Unable to compile shader!

I am lost haha, should I create a thread for this?

Forgive my ignorance, but is calef's fix still applicable then? I'm trying to compile what's in the development branch right now with dx11 and running into the same issue when attempting to load an existing project.

That would be incredibly useful. The transition to DAE support invited tons of new pipelines but the documentation never caught up.

Is that true? Man, I'm actually half decent in C#, guess I've just never had a reason to prefix numbers in variables before until torque's skin tutorial.

Whelp, you live to learn.

good god you are completely and utterly right, feeling pretty dumb. Thank you for taking the time to enlighten this ignorant fool.

Though, gotta say, wish this were annotated somewhere.

but whyyy dad

like I'd wanted to use the skinning system with such materials, but those have to be a prefix, no?

Are you generating them on the fly, though?

I find reading objects etc from file (ie materials.cs) with alphanumeric names works just fine. But trying to create them with mixed names at execution causes them to fail to bind.

I'll clarify. Like, if I were to make a function to create a material or object

function generateobj(%newname)
{
//create new object
%newobj=new object(%newname);
return %newobj;
}

and let's say the %newname param in this example happens to be 'material'

this will work just fine

if %newname in this example is set to be '45617_666'

it will work, you can use the generated object just fine

however, if %newname is set to any combination thereof, like 'material_01', or '111_valkryieskin'

the object will generate, but you can't access it by name. so basically even if it were generated as '111_valkyrieskin' successfully and does exist, any code trying to reference '111_valkyrieskin' will result in a parse error. Note that using the getName method against the ID of the alphanumeric object will return the correct name; it just seems to fail to bind to the ID in the system for some reason.

Which is really odd, because you can create objects at runtime and have them work successfully, and you can have alphanumeric objects loaded from file work just fine (as you point out, I think), but for some reason trying to make an object at runtime with a name containing both numbers and letters just doesn't work the way it should.

Now that I've had my morning coffee I think what I could do is just set up an array for my generated objects (seeing as reference via ID seems to work alright), but just the same I'm still curious how this came to be.

I've come across an issue working with script files

When creating a material or object via script, and just script (ala transient), having numbers in the generated object's name seems to make things screwy.

IE, if I had a loop to create several materials like so

for(%i = 0; %i < 4; %i++)
{
%newmat = new Material(%i@"_testmaterial");
}

output is

0_testmaterial

1_testmaterial

2_testmaterial

3_testmaterial

However, if you go ahead and try to call any of these by script you'll get a parse error.

eval("0_testmaterial.getID();");

output is

parse error.

note: They'll RETURN the name you gave them if called, but basically it seems to be even though you create a material with a given name, it doesn't link up to it in a way you'd expect, because of the numbers. I can create materials just fine via script as long as their names are either pure int or pure string, there just isn't an in between.

I haven't done more extensive testing but this appears to go for more than just materials. Why is this limitation in place?

PS: Have looked through the cpp's but unfortunately the declarations I'm looking at are all 'String', which to my understanding is about as loose as you can get with a variable type in C++.

I haven't been able to successfully run an empty template in the current developmental build, just kinda gave up and rolled back.

Full works, however. Not sure how to figure it.

Okay this is going to sound really dumb but I got it haha

I switched the shapefile in the datablock from the DTS to the original DAE file, and I guess we're in business! That didn't work before, I think the new export settings did the trick.

Thank you so much for your taking the time to assist. There's a lot of stagnant forums where questions like this get glossed over by disinterested members but I'm glad neither are the case here. Hopefully some day I'll have the opportunity to help someone as you've helped me.

I never used them outside of the shape editor, but importing and playing the animations worked fine for me. Creating a new project using the dev branch could help, this isn't the first time someone has reported the prebuilt binaries doing things they shouldn't.

For future reference - torque does not support shape keys from what I recall, its probably best to disable those. Torque needs triangulated meshes but isn't the best at triangulation, its best to let the modeling program do that when exporting. Use translocrot when exporting with the stock exporter, not matrix.

Got back from work and tried re-exporting stuff with that in mind, unfortunately, not much luck.

Once more the animations will play fine in the editor, but when it comes to actually use them in the game they won't trigger.

I tried grabbing a build of the current github development branch of Torque buuut the thing crashes whenever I try to load a level. Something something shaders.

Actually that's not just exclusive to my attempt at porting my project over. It seems like any new project with a build off the repository using the Empty template is doomed to CTD before loading the mission. Not sure why.

Put the files over into a new Full Template project, but again, no luck. Once you get it ingame it'll either be one animation 24/7 or none at all :/

You could try this thread from our forums called:

Blender: Better Collada (DAE) Exporter

Based on the thread it sounds like it has some great DAE export options for animation.

Or this one by our own JeffR:

Blender: Collada Animation export plugin

It's new and in development, but seems to have some promising animation export features.

I've had luck with neither, but thank you for the recommendation. Once I figure out what I'm messing up here I'm sure they'll come in handy.

Are shapekeys bad, then?

What I've been doing is

1) Rig model with armature bones

2) Create armature modifier on base mesh and link to previous

3) Open up Action Editor

4) Set a 'Whole Character' keyframe at '0' and enable auto keying

5) Adjusting the frame and moving bones around in 'Pose Mode'

Blender automatically saves the transformations into an Action under the Armature object. From there I can create a new Action, but this will bury the previous one and make it invisible upon ShapeEditor import.

When I use Blender's COLLADA export on a .blend file with the Action (per above), I kept to the default settings.Apply modifiers was on, as was ShapeKeys. Disabled Triangulation. Importing this into Torque gives the problem I'm dubbing the Eternal Animation. Basically you get the , and the animation you exported as a sequence called 'ambient'. Again, doesn't matter what you rename it, it'll just play. Always :shock:

Conversely, if I COLLADA export with 'selection only' and 'with children' with just the mesh...I just get the mesh, heh. Doing it with the Armature and exporting NO action/animation data results in what you'd expect - just a rigged model. But if you try to add sequences by using animation-only DAEs or even by just DAEs exported with the mesh data intact, they'll show up fine in the ShapeEditor but don't want to trigger ingame.

But throughout it all I've always kept ShapeKeys on in the COLLADA export. Could that really be the problem?

Edit: I am running the latest release build. Win32 3.8 binaries and package. Do you think it would help if I compiled a development build? Also, cubeman does import just fine in the shape editor, but try using it in the real game and see if the sequences play, if you would.

No dice, unfortunately. The one under development would've been cool, but doesn't look like it's finished yet.

Tried the BetterCollada - uhhhh

http://imageshack.com/a/img923/8302/FxLDHW.png

Not entirely sure what happened here haha. Animations still refusing to play outside of the shape editor even with console playthread.

I also tried a DTS exporter updated for Blender 2.76 in the hopes that would magically fix my problems, but naay, I say. Couldn't export a thing on account it doesn't seem to support boners.

Hmm. You know, I couldn't get my precious space marine in because of the linked armature. Coincidence? Are boners forbidden?

Yooo, quick question here. I think, anyway.

I've been working on a project...etc, etc, long story short, I modeled a quickie adhoc model to see about getting animations into the engine. So far I've had very, very limited success.

The first thing I tried was a model I made a while back, one of the Emperor's finest:

http://imageshack.com/a/img922/5234/GZue5R.png

Unfortunately, after a handful of hours exploring Blender's rigging system (3DS user), Torque outright rejected me. Trying to import it with the Armature anywhere in the exported dae resulted in this:

http://imageshack.com/a/img921/852/BKllHJ.png

Download source files here for 'meh' imports

Basically, for whatever reason the camera in the shape editor spawned a distance of 7000 away. Outstanding! Even the editor fears the wrath of the fearsome Adeptus Astartes. But anyway, did some more experimenting before work the next day. What I found out was:

a) Importing with the armature anywhere linked in the dae export induced this problem

b) Unlinking armature created a successful import, but of course, as a shape, bones basically don't do anything

c) Shape imported without segregated bones via collada export options magic made any animation FUBAR

d) No change in scene organization fixed the issue (bip01, start, base, etc)

So I concluded the problem was my model. So, to cut my losses, decided to just grind some Blender exp and make a fresh model, bone it, and then try another go at getting something animated in Torque.

I introduce, cubeman

http://imageshack.com/a/img922/4046/sCHnTS.png

Might be the dumbest thing I've ever made, but hell, I've got no time. Alright, so, got cubey here rigged, strictly adhered to the scene format I spend hours googling and cross referencing, and imported. Wow, did it work? Yes, it did! Ok, let's try getting an animation going.

Whelp. My first issue was that an animation put through Blender ended up appended with some random keyframes to get it back to the 'rootpose.' I mean, this would be cool and all, but when your Action's designed to flip flop and repeat they pose a problem, especially when they won't krekking go away. Tried modifying 'in' and 'out' boxes, but to no avail, Torque is that grandmother who insists you really need those cookies when it's just extra fat that makes crap look bad. Or Blender. One or the other, never was able to figure out where they came from but I suspect the former because of their dogged persistence.

I gave up looking for the source and just reluctantly modified the animation in Blender to return to the rootpose myself. Imported aaaaand, perfect! Animation looks about as good as 5 minutes in the dopesheet can be. Pray tell, what could my next problem be?

For the sake of time I'll just condense the issues I've been trying to resolve, they're pretty related anyway. Essentially, when I try using my new model,

a) the animation exported with it in the DAE will keep playing. Importing other sequences doesn't matter, if it came in with any animation attached that's the one it wants to play 24/7. Very picky and sheltered imo, just saying.

b) exporting just the rigged model without any animations to then import other DAE files as just sequences results in nothing being played at all. Like, names don't seem to matter. In the zip below CUBEMAN5 has a defined 'root' and 'run' sequence but refuses to use either. Levitation is cool I guess but I need you to listen to me, bruv.

So this is a no-win situation. Here's a zip with the CUBEMAN source, dts, and tscript files.

So the crux of my question becomes: how do I successfully import animations via Blender DAE into Torque3D?

Thank you kindly for any responses.