JeffR

It's an increasingly common graphical effect used to make scenes feel more 'real' in terms of how accurate an image looks to how it'd look as taken by a camera. It's also occasionally utilized in conjunction with taking damage or the like to help convey it being bad. But yes, the effect on it's own if used too much looks bad, and IS replicating a camera artifact, it still can be useful in achieving a certain look one may be going for.

I had no idea sqlite could do that stuff. That's pretty sweet, actually, thanks for the info! :)

Looks like you have a terrain material or texture that uses a currently unsupported version of DDS. I'd take a look at any new DDS image files you added as a start. Once you know what new DDS's were added, you can etiher open them up and figure out the formatting to ensure they're the right kind, or maybe just simply try temporarily removing them to isolate the one causing you problems. Once you know which one it is, you should be able to just resave it in the appropriate format and be good to go.

In the current build, D3D9 is the default graphics option and there isn't a simple flag to disable it, currently. Going forward to 4.0, 9 will be dropped in favor of 11(with feature support for 10). So you'd need to disable some stuff in your project to make it agreeable on the win-side without DirectX, but as Linux and MacOS are both GL-only and run fine, yes, you could go pure OGL if you wanted with a bit of fiddling.

Looks like whatever issue you're running into with the scale not applying got fixed at some point in devhead. I spawned a static mesh, visible collision, and tested it in stock, bullet and physx3.3 and it worked in all 3 cases to scale the mesh and have collisions update appropriately. Will need to eyeball the changes to the physics stuff to see what changes were in play there from 3.8.

Site is up for me, so it may well just be some intermittent issues. I'd give it another shot.

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.

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 For the second part, yeah, you can either have collision meshes in the art file itself, which follow a naming convention(I beleive it's if the submesh is named Col-*, where the * is a number). Alternatively, you can load the shape up in the shape editor and use the collision tab to automatically generate convex hull collision meshes. It's easier than doing it in a modelling program, but because it's automated, may not give the preferred results. Either way, either of these methods will work.

Currently, yeah, the older SDK is required. Ironically, not because of DirectX, but because of how MS decided to hatchet-job the audio dependencies with XAudio. We're looking at how to resolve that what with dropping DX9 shortly after 3.10 goes out, but due to the knuckleheaded way Windows deals with the audio stuff, supporting XAudio at the moment with pre-8.1 windows necessitates the DX SDK.

Another option, if you don't require it to be physically based, is to just edit the mesh/animations to make the character float off the ground.

Oh, yes. If you switch to one of the physics libraries, rather than the stock torque physics, then I beleive the only thing that would still utilize the stock physics is the RigidBody class. Everything else will internally switch over to go through the physics abstraction api.

Can't say I'd spotted that issue before. but thanks for pointing it out. I'll definitely have a look at it.

What do you mean by 'multi-client', exactly? A multiplayer environment, where players exist in a game that has physically enabled objects? Or some sort of distributed computing situation. It can do the former.

Very cool stuff, as always. Speaking of game music, I'd always been fascinated with games that use persistent themes throughout, leitmotifs, if I remember the name right. I'd enjoyed bits of it when it showed up, but a game that seriously rocked the concept into the stratosphere was Undertale. Did you ever play it, or hit up the OST? The use of leitmotifs to tie themes together even before you run into characters or associated characters with areas is pretty incredible when you go back and look at it afterwards. Was just curious if you'd ever experimented with that sort of thing before. It's such a deep and fascinating concept to me.

Most excellent. Keep up the good work! :) And yeah, there's a built-in utility method for baking meshes together. As Az mentioned, we need to get LODs and probably animations working at least. Also want to get an option in there for baking the textures into an atlas as well for further cut down of drawcalls, but that's less critical comparitively.

Ah, thanks for reminding me! I need to port the T2D documentation on the modules, assets and TAML to our wiki. The systems were originally from T2D, but ported over and being expanded upon. Here are some relevent links: https://github.com/GarageGames/Torque2D/wiki/Module-Manager-Guide https://github.com/GarageGames/Torque2D/wiki/Asset-Manager-Guide https://github.com/GarageGames/Torque2D/wiki/Taml-Guide

Yep. You basically get your base textures, then can do a sub material per color channel.

It'd be like if you had a terrain block with only 4 verts. Each corner could have the blend effect applied on it, but it would influence the entire quadrant of the mesh in that corner. Sort of. You're still only using one actual material. As with the video, they weren't swapping back and forth between brick, water and sand. It was one material with multiple diffuse, normal and spec textures, each set associated with a vertex color value. You paint blue on the vertex and it blends the default texture with the sand texture for example. So you're only using one actual material, and you don't actually bake anything into a final texture, it's handled runtime in the code.

Yeah, how detailed you can get with the painting is 1:1 with how dense your verts are, even on flat surfaces, you'd need to have them modeled as a grid.

Kinda. This part of a video from UDK shows it off a bit: iAvupgMlvKE One of the advantages this method offers is a single material, but nearly infinite variations in surface. This is especially useful in cases where you have a bunch of prefab parts to make buildings. Obviously if you just used the same peices with the same textures, it becomes really repetitive, but having a bunch of different textures uses more memory and adds draw calls. So you could go in there and using one material, paint grime in various spots, breaking up the repetition without tons of additional memory use and draw calls. The thing that separates it from a simple texture overlay is you can use the normal maps as a contributor, so as the video shows, is when he paints the sand/water, it accumulates in between and at the edges of the tiles first, which is more realistic, and then the flat surface areas. You can also mix and match a few different materials, or have it offset the verts in the very shader to have sand accumulation actually raise off the surface for more depth, etc. It's a pretty flexible technique.

It's similar to how the terrain texture blending works. In fact, that's one of the most common ways to control which textures are where on the terrain - by changing the vertex color values - and is similar to what we do with our terrain. For more specific examples, it allows you to do stuff like having, say, a brick floor material, and then additional texture maps/materials that blend in as needed like, say, water and snow. So you'd have your brick floor on your ground, and then by painting vertex color values, can dictate spots to have water and snow accumulation, letting you pick specific parts of the ground to have water puddles, or snow piles. This can be extrapolated to practically anything. Stone wall with greenry growth or grime, cracks in concrete, etc. Because you select what parts of the surface have the various blends, it allows you to take a common material, and apply minor changes via the blends, adding lots of detail as needed and also helps combat the 'repeating texture' effect. All in all, a very powerful tool for artists to work with to make their scenes unique and interesting.

Haha, no worries! You can either make a thread here on the forums, or you can make an issue on the github page, just noting it's a feature request so it's easier to organize. You needn't worry about getting in trouble for suggestions :)

Good to hear! Over the next day or two, I'm gunna go in-depth on the particulars of the assets, entity/component and game object stuffs in my workblog thread, so feel free to keep an eye out there for more details on how this will all get utilized :)

Sure! https://github.com/Areloch/Torque3D/tree/BaseGameTemplate That's the current build of it. It's a bit behind to devhead, but i plan on updating it soon. It has a module that contains all the current Full template's fps/gameplay stuff, so if you started working on something now, you could port it over to that module without a huge amount of hassle. If you wanted to look at how the assets and entity/component stuff works, you can nab my R&D branch https://github.com/areloch/Torque3d/tree/RnDBuild Where I do all the testing and building for the modules/assets/entity-component and all that jazz. If it's in my workblog posts, it's in the RnD branch. I do plan to put together documentation explaining how you can port to 4.0(while existing game classes like ShapeBase, Player, Item, etc will be deprecated, there will be entity/component versions that come with 4.0 that do the same thing, so you don't need to start from scratch or anything, merely port over). Let me know if you had any specific questions :)

Hey man, no worries! 3.10 is largely fixing bugs and some quality of life improvements, but we also wormed some new features in. It's not exhaustive a list(that'll come with the changelog for the release) but here's some highlights for 3.10: Added MacOS support Updated some of the libraries, like bullet, vorbis, png, and recast Various fixes to D3D11 and OpenGL, which help stability and performance Ipv6 support OpenAL-Soft audio support(better than the old OpenAL) Replaced OpenGl's epoxy with GLAD, which is cleaner and simpler for building out the GL feature list. OpenVR support, which allows you to use the Vive Hardware Skinning support A bunch of fixes and tweaks to lighting stuffs to make it all play better with the linearized lighting And as said, a crazy number of other fixes and tweaks aside from these(So far, we have 105 PRs merged in for 3.10, with a few that'll go in before release yet) For 4.0, it'll be a pretty gigantic update and improvement in a lot of areas. I'd suggest poking through my workblog thread for some ideas on stuff I've been working on my side of it in line with it all. Important highlights are: Dropping D3D9, allowing us to modernize the GFX stuff for OpenGL and D3D11, which should help bring a lot of performance improvements and new features like compute shaders down the line Full switchover to a linear color system, specifically utilizing sRGB textures internally, which are a) better performing because the hardware does the dirty work, and b) all colors to be very consistent and correct across platforms and tools/workflow. PBR(Physically Based Rendering) for the primary material lighting model. This will allow materials to look much more realistic, and have far, far better integration with modern toolsets with less effort. Updates to HDR and tonemapping, which will perform better, look better, and behave a lot more consistently. Hardware PCF shadows, which will look nicer AND run faster A drastically slimmed down gBuffer, which will help the engine run better on older hardware A new base template that has all the cruft trimmed out, so it's easier to use, change and loads faster. The new template will also heavily utilize the new Module/Assets system, as well as make the Entity/Components system the standard for game classes. The huge monolith classes like Shapebase will be deprecated, and down the line removed. This will MASSIVELY help cut back on iteration and testing time, allowing people to focus on gamedev rather than fussing. Updating the stock Torque physics to hook through the Physics abstraction API, so game code is consistent regardless of if you use, Torque's physics, Bullet, or PhysX Drastic improvements and updates to the tools and editor suite, including visual editing of shaders, state machines, more benchmarking tools, etc. Shift all the platform code to utilize SDL, letting us get rid of a lot older, platform-specific code and make things a lot more consistent Big expansion on included starting examples, as well as better documentation and tutorials. Code cleanup, including making sure files are adhering to the coding guidlines, and removing a lot of unwanted cruft, excessive includes which drag down compile times, and not-errors-but-not-right code which can cause bugs and irregular behavior, which should help stability of the engine across the board. I think that covers the major highlights of what the plan for 4.0 covers. I said earlier I'm working on a proper Roadmap/Master Thesis breakdown of the plan for 4.0, and thankfully while that list looks daunting, a huge amount of the above is either actually done, or rather far along already, just waiting for us to get 3.10 out the door so we can start merging stuff in. Lemme know if you have any other questions ;)