LukasPJ

Actually @buckmaster was working on a multiplayer version for T3D-bones afaik.

Not sure he ever finished it, but check out the ghosting-test branch on his Github, at least there is a good tutorial there on how the client-server system works.

@andi_s not entirely sure, but I believe we made wiki edits open to everyone yes. So just log in with a WikiDot account and edit away!

This is the 3.7 PR, and shows the list of commits made: #1328

Sounds like something I'd solve using a skybox

I'm curious, can you replicate this in stock, with stock assets?

Probably gonna work on Windows 10 yes, dunno about the other OS's, someone else gonna input on that. But I believe the OpenGL version will be ahead of the DX version when it's stable.

Anyways, MS is prolly not gonna drop DirectX9 support anytime soon (Win8 still supports DirectX7 IIRC). Mac and Linux support is not far apart, so when it supports Linux then I believe Mac will come shortly after.. If anyone here with enough interest owns a Mac that is :P

Can i control the spawned ParticleEmitter via script? Play, stop, change it's parameters? For example, i might want to randomize some of the properties, like velocity, etc.

Are there any examples of ParticleEmitterNode in the docs?

The issue is that, all of those parameters are datablock-parameters. So it's messy to change those values at run-time, since it doesn't copy the values from the datablock, but uses the values directly from those datablocks.

There are plenty examples of both ParticleEmitterNode and ParticleEmitter here and there. You can use this part of my "Coin Collection Tutorial" for an introduction on how to create ParticleEmitter's at run-time. http://wiki.torque3d.org/coincollection:visualeffects

Do you spawn these billboards manually or are they a stock feature that you're using? (Not too much into that side of the engine)

Could you possibly share an example of one of the shapes that causes a crash when not commented out?

Can you elaborate? The current system is pretty much bound to emitting particles in spherical volumes. It can't do more than that so if you mean you want to control specific particles individually through script then that is not currently possible without the ParticleRefactor afaik.

If you just want to spawn a ParticleEmitter, well then that's basically how you do it.

You can't spawn a ParticleEmitter by itself, what you need to do (if you're working purely from script) is to spawn a ParticleEmitterNode and mount it to the gun whereever you need it to be, and give the Node a reference to the desired ParticleEmitterDatablock.

Just to be clear, T3D is just as capable of importing World Machine terrains as UE4 and the like :P

You still haven't shown a screenshot of the issue so tbh, I'm still not quite sure what the issue actually is, which makes it hard to help you solve it. the smooth tool, smooths out the terrain i.e. it sort of flattens it without removing the slopes right away. So yeah detail will be lost in the progress, but exactly what detail is it you don't want to lose? What you want to do is to remove spikes etc right? So you need to smooth the spike, such that it looks more natural, so you use the smooth and a suitable brush to flatten it.

Alternatively you could use a "lower height" brush with 1 vert radius and use that to manually adjust the detail, this is pretty tedious however and doesn't always provide better results, so the smooth tool is the "shortcut".

World Machine is one of the 2 solutions people use (outside L3DT which I personally believes uses inferior algorithms, and provides worse looking, but playable, terrains. Many uses World Machine, I personally use World Creator.

I usually use 2048x2048 and get fine results from it, I don't know what triggers your issues, can you screenshot it?

IIRC it smooths relative to the other vertices selected by the tool, try using a bigger brush, can't tell for sure what you're actually doing though.

Edit: btw, increasing geometry resolution probably doesn't help on your shadow results. The shadowmap has its own resolution.

How can you increase terrain resolution? Or the shadow resolution? When i try to smooth the terrain, the tools end up adding even more triangles, with terrible shadowing results.

There is no tool that "adds triangles".. There is a fixed amount of triangles, what you can do, is change the LoD settings, such that there you push away the distance at which the terrain loses quality.

Shadow resolution, I believe is a property on the sun or scattersky object. Can't remember though, maybe someone else can pitch in here?

@saindd when WorldMachine generates a terrain, it does so for a terrain that's typically designed to look good at a distance (at least, I know this is the case for World Creator). So, therefore you have to adjust, and smooth out the close-up detail as Duion suggested, such that the terrain becomes playable.

The reason for this is that WorldMachine aims for realism, and realistically a terrain has almost infinite detail, however we have a limited budget for rendering our terrain and have to limit the resolution of our terrain. Therefore, you typically don't have a lot of detail up close (but you do have some ofc), and then for that fine up-close detail, you use rock models and foliage.

As for the splat-map, it looks odd. You may have to turn it upside-down, can't remember if that were fixed. I made tutorial for exporting from WorldCreator to Torque3D perhaps, some of it could help you do the same for World Machine.

Edit: also remember that out-of-the-box Torque3D is set to pretty low graphics settings, the shadow you see in your screenshot is therefore of a very low resolution (but looks fine up-close) you could turn up the visible-distance of the high-resolution version of this shadow, to get a better idea of how your terrain actually looks.

Edit Edit: This is also true for the resolution of the terrain itself.

The issue is that, pulling in someone outside of the community is more expensive than someone who already knows T3D and doesn't have to put time into learning T3D. Further more, hiring someone will be immensely more expensive than someone doing it out of goodwill, and the small reward. Example, getting a wikipage written could cost 100$, vs. 10$ if someone does it out of goodwill.

The idea is to generate a community that wants to do stuff for the community, the bounty system let's people incentivize and reward the people who work on it, not to fund new development teams. I don't think we have enough funds to actually hire someone to work on the engine.

@Johxz

You could put a bounty on the creation / polishment of various wiki pages.

You can find the bounty-page button at the bottom of this page. Unfortunately, it seems it hasn't quite taken off yet, perhaps I should create some bounties for smaller tasks and see if that can kickstart things :P

Edit: Simple example of a bounty on a wiki-page: https://freedomsponsors.org/issue/717/wiki-page-built-in-posteffects

Certainly possible, but I'm hesitant to implement more features if you're the only one who uses it :P Personally this is the first I've heard about it.

Hi,

Few days ago I downloaded the engine and started looking through TorqueScript code to more idea how the engine works. I'm still very fresh but I saw this discussion on TAML and thought this might be relevant:

From what I found out in my investigation of scripts, is that there is also tons of stuff in core/ that could be implemented as TAML. This might result in faster engine initialization and definitely better learning curve as there would be less code to look at.

Particularly this files:

core/scripts/client/postFx/* (most stuff)
core/scripts/client/lighting/* (most stuff)
core/scripts/client/audioAmbiences.cs
core/scripts/client/audioDescriptions.cs
core/scripts/client/audioEnvironments.cs
core/scripts/client/commonMaterialData.cs
core/scripts/client/materials.cs
core/scripts/client/renderManager.cs
(^ perhaps DiffuseRenderManager could be implemented in TAML)
core/scripts/client/scatterSky.cs
core/scripts/client/shaders.cs
core/scripts/client/terrainBlock.cs
core/scripts/client/water.cs

My concern is that this would require to split every object to its own TAML file, causing shitload files to load and potential IO performance problems. Plus all that objects would still be global. But maybe tweaking some of this files on C++ side to be SimGroups or adding composition syntax to TAML (property = new Object) would solve the problem.

You'd prolly just throw it in a SimGroup as you suggested. Like "WaterGroup" "TerrainBlockGroup" and then it could be thrown into a single TAML file. And yes TAML is significantly faster than TorqueScript.

I never did finish the Myo implementation (biggest issue was that it was queueing data when game was minimized) but you can find my implementation here.

Alternately I simplified it to show the gist of it here. (Untested code)

I am by no means a guru of input devices, so I'm not much of a help, but that should give you somewhere to begin. What I did was to simply copy and paste the LeapMotion code, and replace the all the Leap stuff (you'll find residue in there though because I never cleaned it properly).

Edit:

That should, btw, bind "orientation" to the "xxx" device, used like this in TorqueScript:

moveMap.bind( xxx, orientation, orientationReceived);

Example:

function printOrientation(%roll, %pitch, %yaw, %angle)
{
   echo(%roll SPC %pitch SPC %yaw SPC %angle);
}
GlobalActionMap.bind(xxx, orientation, printOrientation);

I think it's more a case of finding it an issue that GarageGames actually owns the copyright as much as it is wanting personal copyright. It can be quite annoying that you spend days on some feature and/or changes and then have a "GG owns this" stamp placed on it.

But porting it is still a good idea, then people can easily implement it into the engine by themselves.

Afaik, the offline LPV actually can't be included into the main repo because of copyright issues. Something that has been vividly discussed, and I don't think the author ( @andrewmac ) will allow the GG MIT header.

Tbh I support him in his position on the matter.

Actually doing that blockly thing sounds cool :P Does anyone have experience with that?

@jay1ne I meant that deferred shading is already in stock aka main repo.

Just curious has anyone ported this to deffered lighting (default per pixel) successfully yet?

I played with it in deffered shading and I feel it would be a great addition to the main repo, granted anyone being successfully at the port..

Seems like deferred shading is already in there or am I misunderstanding something?

If you're an artist: go for the full template, if you're a scripter or coder: you should really use the barebones template, as you will have complete control and understanding of how the project works and you wont have any unnecessary code flowing around.

Also, it's so welldocumented that you can piece a game together even though it's barebones.

@saindd not in any foreseeable future, I was planning to, but I haven't worked on it for a while, and now I'm working with C# so I don't have a use for it atm :P

But yeah, try out TorqueDev, it's open source too.

@saindd, well an example could be the C# bridge that I'm working on.

This is an example of header and source written in C++/CLI.

With that kind of wrappers I can get C# scripts that look like this.

The engine I'm working with (Torque6) doesn't have an adapter so I made one for Engine->CLR calls : here

Torque3D has this which you should be able to bind with, alas I have no experience with it.