Mitovo

Thanks for the details MiToVo.

I'll fire it up with PhysX and have a look. Most likely thing is when the object scale changes, that's not applied to the physics rep, so it never passes along to the physics sim.

I'll let you know what I find.

Sounds good! Thanks!

I have a sandstorm effect in Uebergame using the precipitation feature that normally does rain, is that what you want?

If it's a very slow-moving sandstorm, then yes, that sounds like it might work. I hadn't considered using precipitation in that way. Clever!

I just tested myself and for me it works.

What build are you using? Are you using bullet or physX?

It's 3.8, and I'm using Physx.

I'd confirm which PhysX version, but now T3D won't get past the "loading datablocks" stage so I can get into the game/editor. Ugh lol.

Hello again,

Back with another question.

I'm working on trying to create a kind of "volumetric fog"-like effect in T3D. The kind where you see the light puffs of fog/cloud in the air as you're running through an area, or maybe on the surface of a lake or something.

If you recall the effect in the old TGE/TGEA "Mars" demo, where it's that sandstorm kind of effect, something like that, which is spread over a large/defined area. Only I want the particles to move a lot more slowly, of course.

Checking the documentation has gotten me part way there, but there's limitations I've run into. It seems that, aside from the "offset" option (which doesn't get the effect I'm after), there's no way to make it not originate from a single point. I also can't get the lifetime long enough to make it float for very far before it disappears. The only way to do that, it seems, is to increase its speed, and that would work against the effect I'm after.

Any other documentation other than on the official site that goes into this at any depth? I've not been able to find anything else that's been useful to what I'm trying to do.

Thanks!

Here's a video I just recorded showing what's happening. This is the process I've used for any other object I've imported, etc, and this is the first time it's doing this, at least that I can recall.

http://tinyurl.com/zp272zv

Maybe someone will see a clue in the video as to what's happening. Apologies for the awful frame-rate. Apparently Corel VideoStudio's recorder isn't very good for 3D games, and NVidia's recorder wasn't cooperating with me. Still, it gets the idea across.

Hello, again,

Just noticed something else that seems odd, to me anyway. Not sure if it's intentional or not, but here goes.

I noticed when working with the settings for the overall "thelevel" info that different color values are used between the canvasClearcolor and fogColor options.

Fog Color appears to use values from 0.00 to 1.00, while canvasClearColor uses 0-255. I noticed this because I was experimenting with the colors and wanted to see different effects, including if I made both of those values the same.

Is there a specific reason why each uses a different method? If not, is it possible to change each to use the 0-255 in a future build? Or even with the option for hexadecimal, etc? Maintaining that consistency could make it easier for designers/artists to make sure they're matching colors correctly, etc. In my personal opinion, either replacing or augmenting the "0.00-1.00" system that seems to pervade T3D's options would be a good idea. Having to tweak numbers 2 or 3 decimal places down to get an accurate result is awfully fidgity lol.

Thanks!

Okay, I just noticed something.

When I scale up the object, the visible mesh is increasing, but the collision size is staying the same. So, the larger I make it, I'm able to run further into the visible mesh before I hit the collision.

Now, I've tried finding a way to update the collision mesh after increasing it, but have not been able to do this.

I've also tried adding it as a new object, from the original DAE file, increasing the size first, *then* setting the collision, but that isn't working either. Still getting the same effect. The collision mesh is being created at the original size of the object.

For the first part: do you know if it stays broken if you scale the object, save, exit and reload? Or does it work if the object is created with the new scale? That'd help narrow things down

Hi there,

I meant to include that in the previous message, but forgot to add it. No, saving, closing and re-opening the file doesn't help. Not sure how you mean creating it with the new scale? You mean create a larger version of the object in Blender and then import that?

Hello,

So, the title pretty much sums it up. I have a custom mesh I've imported into T3D, and I set the collision to "visible mesh" (I intend to create proper collision meshes at a later time, but this is just for set-up/mock-up work). I notice that I can rotate the model how ever I want and collision works fine. However, when I scale it, the collision breaks and my character runs right through it. I have multiple duplicates of the same object in my scene right now, and the ones kept at, or very near original size work fine. The ones I've scaled notably larger lose their collision.

Is there a way to fix this, or kind of "refresh" the collision to work on the larger mesh size on those objects?

And while I'm at it, a second question, can you have multiple collision meshes per object? Since collision meshes need to be convex, it would make it difficult to create a convincing looking collision mesh for an object that has an overhang or is otherwise concave in shape, without the player hitting an "invisible wall".

Thanks!

So you can only do 3 materials with that? Does not sound that good to me. Currently I use the vertex paint for adding diffuse color to the textures, this gives you an individual diffuse color tint for every polygon in the level without adding materials or textures etc. This seems to be a better use of the vertex paint to me.

I've seen up to 4. Base texture, then R, B and G channels.

Also, it's not a binary, mutually exclusive matter of "which is better". Horses for courses.

If you're looking for the ability to change the coloration of the same texture across a surface, and that's all you need, vertex color is ideal.

If you're looking for having up to 3 or 4 different textures on a single object, multi-texturing is ideal.

If you want the best of both worlds, you could probably mix both together - use a splat map for the multi-texture part, and then vertex color to change the tinge. I've mixed these two in Blender, but again, not sure how that would apply to a material in T3D

A single project can use both for different things.

Should note the vertx painting approach specifically (as oposed to a splatmap, which would be a 5th texture where you reference rgba for your blend ops) does require a higher than normal polycount for lookup, pretty much by definition.

I actually prefer the splatmap approach, as it gives far more direct control, but vertex blending works as well, though it can really look like vertex blending if you're blending across a large polygon. Not that anyone but someone who knows what vertex blending is would look at it that way lol.

I'd worked out a node setup in Blender that uses a splat map approach and it's awesome. Thing is, I don't know how to translate that into a format T3D would understand, and sadly baking to a single texture tends to result in really low resolution texturemaps, unless you make them all huge; especially on large objects.

Hi all,

I've tried googling, and I saw the question was asked back on the GG site, but the link wouldn't load... Thought I'd ask here.

Has anyone ever put together a shader for multi-texture, using either vertex blending, or perhaps a splat-map type setup?

I was thinking of working on some assets using something like that, but am not sure if T3D would support such a thing.

Well that's a first. I actually posted something useful!

:p

I'll have to check it out later after work.

Thanks!

For those asking,

I'm using Bullet Physics, and OpenGL rendering, and I'm using 3.8 (can't seem to get 3.9 to work right).

But really, should the physics version really matter? I'd imagine the terrain system would be programmed to recognize when a part of its surface has been set to "empty", regardless.

Just got this tested and working with PhysX 2.8 SDK and versions T3D 3.8 and 3.10. I don't see any floating issues so far..

rDwe6tAvVXc

You should probably post more details about your setup.

It looks like you've lowered the terrain at that point, as you have the sandy ground at the bottom of the water/pool.

In my case, I've set the terrain to "empty", so there's actually a hole in the ground, which I have my 3D model set into.

So, the terrain is visibly not there, but it appears the collision is still being calculated for it. The collision on the 3D model is working fine; I have collision set to "visible mesh" on that. It's only when the terrain is present in the map that it's not working and I'm "running on air".

Also, the problem isn't even related to the 3D model. Here's a screenshot I just took where I'm outside that 3D model, on an area I'd just set to "empty", and am getting the same result.

http://dl.dropboxusercontent.com/u/53548203/Screenshot%202016-12-19%2015.17.35.png

I don't recall which physics I set it up with, unfortunately. I want to say it's either Torque or Bullet, though.

Hello,

So, I decided to test out an in-progress build of a land feature I'm working on, with a quick and ugly texturing job, and I noticed a bug in the terrain system. Maybe it's known about, but I couldn't find anything about it.

Basically, the game engine ignores holes in the terrain for character collision, but it seems to work okay for other items; I threw out one of the mines, and it went through the hole as it should. The model is set down into the ground, with the area inside it emptied out, as it would be in an actual scene.

I thought maybe it was an issue with my model or something during export, so I did an A/B test... one with the heightmap terrain, and one without it. Without the terrain in the scene, it works fine.

Here's a couple short vids demonstrating it...

With Terrain

Without Terrain

Any idea why that might be happening?

Just wanted to post a couple thoughts here, quick, about the Sketch tool in T3D.

I've been working with it, and love how quickly you can rough out objects and shapes, etc.

While working with it, a couple things seemed odd about how editing the objects works.

1. The 'Split Edge' (or is it face?) tool. The effect of the tool is a lot like a mix of a "split polygon" and "chamfer edge" tool in a 3D modeling app, right down to the ability to "bevel" multiple times to get a more rounded edge. All it's missing (seemingly) is the ability to select the specific edge(s) you're working on. Is there any plans to expand on this tool in a future release? If so, I think adding the ability to specify which edge(s) you want to "bevel" would be a great addition. Also, the "face split" tool could become its own tool, so you can split the face horizontally or vertically; this could make something like, say, creating steps or something like that alot easier.

2. A kind of coordinate or "size" label showing the dimensions of a new object is when selected, particularly in the orthographic views. Hammer Editor, and some other editors I've worked with have had this,and it takes the guess work out of making sure you're creating objects to the desired dimensions...less eyeballing required.

Anyway, those are my thoughts on that!

Thanks for reading.

That could always be helpful; having a reference/link or summary/refresher of concepts taught in a previous chapter/lesson is certainly good for someone learning something for the first time... it reinforces what they already know, or helps them remember what they may not.

For the function/twofruity example from 3DGPAi1, my approach to that bit would have been to not jump straight into that large/involved of a demonstration, but to do something like...

Example 1. Demonstrate how to print out the contents of an array with a for loop as it was already taught by, say, using only the quantities of fruit, and leaving out the prices and the other category.

That would be a reminder of how to use a for loop and how arrays work (things previously covered), and would also serve as the foundation for the actual lesson.

Example 2. Repeating the same process, same array, same contents, same result... but placing the array and for loop inside a function, which is called from elsewhere in the program.

This way, the reader/student is seeing a direct, side-by-side, a/b comparison of what the function is accomplishing the same task and, thus, how it works.

It builds on and utilizes previously learned concepts but doesn't overpower the key concept for the demonstration... functions in this case.

Yeah, the sketch tool uses the normal of the surface clicked to orient the brush when creating it.

If you don't want that, currently, you can click the little cube icon in the top bar, and it'll make a 1m cube, 0 rotation. That would likely be useful.

For improvements, I could see a option/setting for conforming to the surface normal or not when creating new brushes.

That could be useful, indeed. I have some other thoughts, having worked with it more, but I'll start a new thread for that, as I don't want to derail my own thread :p

You can feel free to add me in skype, my email being Areloch at gmail dotcom.

I dunno if I've got time to do a full-on sitdown lesson, but I'm more than happy to answer questions and help get you sorted :)

In the interest of plotting out better documentation and tutorialstuffs in the future, what parts of video or written tutorials throw you off?

Well, the problem I run into, generally, is that I'll be following along with a set of tutorials/lessons, and doing fine. The material is being taught in reasonable, bite-size chunks, with all the concepts being clearly explained and built on with each proceeding lesson.

Then, at some point - and I always envision this to myself as the author getting bored or impatient, or forgetting they're supposed to be teaching people this stuff - the next lesson suddenly blows up into this much larger mess of new concepts and information that hasn't been well explained or taught yet, but is ostensibly intended to demonstrate the previous, much simpler concept you'd just completed.

This most recent example involves a lesson out of the 3DGPAi1 book, which I'm following (I still prefer a physical book to flip through over following something on a computer screen). It's the chapter on functions, the "twotyfruity" bit. Now, I understand functions. I understand what they do (they're effectively reusable miniature programs in your code designed to achieve a specific task). But the way they're demonstrated in this lesson has me completely confused - and not even by the functions themselves, but by the (to me) crazy use of arrays used in demonstrating them. There's 3 different arrays set up within a single function, all using similar syntax, but only a single reference used to access all of them, though they're being accessed individually elsewhere in the code. The result is, I can't follow what's going on in that program. I don't know what Ken was thinking when he decided *that* would be the best, most direct way to demonstrate functions in TorqueScript to a new learner.

Sometimes I get the impression that people who create these tutorials/books/videos are more interested in showing off what they know, than they are in teaching. I've only found a single book so far where the author doesn't run afoul of this.

Now, if I had the opportunity, a time-frame where I could speak directly to Ken and say "I can't wrap my brain around what's going on in this lesson example. Can you walk me through it?", or something similar, that would be a huge help.

The frustrating bit is, I understand all this in concept. There's nothing I've seen, yet, that I don't grasp conceptually. It's how to make it all work syntactically that is throwing me off. So, when an author throws all these crazy new, unfamiliar - or at best, barely familiar - things into the mix, it's only confusing me, because now I don't know what's actually relevant and necessary to the specific topic, and what isn't.

Anyway, long-winded reply there lol. Sorry.

Thanks for your time.

Hello,

Almost put this in the jobs section, but as it's not related to a game or other such project, I felt it would be better here.

So, I'm posting this as a request to see if there's anyone in the Torque3D community who's experienced and fluent in TorqueScript who might be interested in giving some paid, personal lessons? The means could be something like a Skype call with a shared screen or something to that effect?

I'm asking because, as with every other language I've tried to learn (Python, Javascript, PHP, etc), I find that I inevitably hit a wall in the training in the form of the author/creator seeming to forget they're teaching alien concepts to people completely unfamiliar with them. It's usually got something to do with arrays. Now, I suppose for some that's fine and they can work through it. For me, I like to make sure I understand the concepts completely before moving on to something new, or building on them. I don't learn well through rote memorization; never have. Unfortunately, book or video learning is entirely one-direction, and so there's no way to ask questions, or ask for clarification on something that doesn't "click".

I could ask questions here about it, but that would require me first knowing if I'm even asking the right question, and possibly attempting to type up an entire example, outside of the context of the lesson it was part of.

I've come to the conclusion that book and video learning just does not work for me. I feel like I need some live, real-time training with a living, breathing human being, to help me grasp this stuff.

So, I don't know if anyone in the community does this, or would be willing to, but if you're fluent in TS, and feel you can teach a beginner in an organized and, preferably, project-oriented context (like a simple game, pong, etc), that would be great. Even if it's something like... a 30 minute lesson to teach a concept, with "homework" to do for the next one, etc, that would be great.

If anyone feels they'd like to give this a try, please PM me with your cost and availability (I live in EST and am available every weeknight after 6:30PM, or "when ever" on the weekends).

I really want to learn this, so I can begin to actually work on these projects I've been wanting to do forever. I just need assistance wrapping my head around this TorqueScript thing that I'm just not finding in written or video tutorials.

Thank you for your time/help/consideration.

Not sure what you mean, you can use in a terrain, see

. I have a basic level, all was made with some meshes and the sketch tool. Even you can use a texture for your sketches props. See this

and this blog

Well, like I said in that post, any time I try to draw out a shape on a terrain with the sketch tool, it comes out wonky, crooked, etc. It just didn't want to maintain a flat, orthogonal orientation, even if drawing from one of the orthogonal views. I'm just noticing how if I start on a purely flat surface, that's never a problem. It comes out exactly as I would expect it to.

Here's an example...

Here, I've dragged out a brush on uneven terrain... - It comes out lopsided, sloping to match the angle of the terrain at that point.

Here, I've dragged it out on a flat plane, and so the brush itself is flat.

And just to be thorough, I flattened out an area on the terrain, next to the other one, and the brush comes out flat and straight again.

Hi @MiToVo

Some what related, I'm doing a few video tutorials here right now I don't have for TS, but I have in my roadmap add video tutorials for TorqueScript, so if you want to superscribe.

You know, a little bit after I replied to your post, I went on YT to find some good T3D vids to listen to while working,and happened up on your Sketch Tool tutorials. Bummer that there's no voice-over (I can understand why, though, given your comments about editing, etc).

I'm checking them out now while on lunch and noticed something that hadn't 'clicked' with me before. I think every Sketch Tool video I've seen takes place on a flat, regular surface, not on a terrain. I think that might be the answer to something that's kept me from using it more in the past, as a 'mock up' tool.

I would use it on a terrain, and would find that the blocks were never aligned orthogonally on all axis. It would always be rotated or skewed on at least one, if not multiple, even if drawing from an orthognal view,like Top, etc. I'm going to guess that the way they're drawn out is determined by the slope of the surface they're initially created on and that's why that was happening?

If that's the case, then I'm a very happy camper, because I'd been wanting to use that tool more, but it always felt wonky to me.

I recommend to get the .chm files of the script reference that you can get from

http://forums.torque3d.org/viewtopic.php?f=25&t=751

There's a lot of info about classes, too. It's my main help guide for scripting.

For example you can get info about echo() that is the console print for torquescript.

Excellent resource! I'll keep that bookmarked. Thanks!

First..

Apologies for the "cranky" tone of my previous post lol. I have to learn to not post before I'm fully awake and caffeinated. I'm still talking in my "need coffee pronto" voice at that point, and tend to sound irritated when I say things lol. Anyway!

Download Torsion from here: http://ghc-games.com/SC/Torsion.zip *1

Ah! So I was in the wrong place, then. That makes more sense.

A lot of tutorials still relevant even from TGA or TGEA or T3D 1.2 of course you need to change a few thing if the tutorial use a very old version of the engine, either way you can use the book you have for learn TS, just remember use the same version of Torque that was provided in the book, and then you can use the new T3D version.

BTW :roll: Not sure if you saw this http://forums.torque3d.org/viewtopic.php?f=8&t=835 but you have plenty of tutorials and more stuff in the list, even you can learn from TS resources. Please give a peek... if you think you need something that is not on that list, send me a PM and I will updated or you can do a PR.

Some what related, I'm doing a few video tutorials here right now I don't have for TS, but I have in my roadmap add video tutorials for TorqueScript, so if you want to superscribe.

I see! So, really, very very little has changed between versions, then. That's good!

I have looked around for tutorials, and found a lot, but again, since they referred to older versions of the engine, I figured they wouldn't be applicable/compatible with the current one. Glad that isn't the case.

I actually did install the 3DGPAI1 package and started to work with that. Right off the bat, though, I ran into trouble with the "hello world" tutorial. They have you typing (along with a bunch of comments):

function main()
{
   print("Hello World");
}

... which didn't work. I couldn't even get it to launch from command prompt (per the instructions) by typing that tge -ch2 HelloWorld.cs (maybe not exactly what's typed but I'm remembering off the top of my head here; don't have the book atm). Torque kept saying it couldn't find the file.

I tried running the code from inside the console, and it said that there's no function called Print. When I looked that up, I learned that there's no 'print' function in Torque Script. Then, that it was something unique to the version of TGE that installs with 3DGPAI1, which is what I was using, but it still didn't work, and I couldn't find anything else about it. Echo worked, but not Print, which is what the tutorial wanted me to use. So I just gave up and figured I'd wait to find out what I could about just going with T3D lol.

Not sure why Ken would be using commands that aren't normally included with TorqueScript, but I'm sure they had their reasons.

I wouldn't *mind* starting with an older version of TGE, as I assume it's a bit more "stripped down" without all the additional features of T3D. And if TorqueScript is effectively the same, then it should be useful, but... I can go with T3D all the same.

Anyways.. thanks again!