Work Blog - JeffR

455 posts Page 26 of 46
Posts: 1500
Joined: Sun Feb 08, 2015 1:51 am
by Duion » Sat Jun 30, 2018 8:43 pm
Ogre3d lost all momentum when going for 2.0 and never really recovered. Neoaxis went for 2.0 and has seemingly died a death. Even massively popular projects with a huge community like AngularJS for example have lost loads of ground by trying to reinvent themselves too much.
So you know the reason already why I say, don't start over and redo everything.

Torque is more complete and proven than probably any other open source game engine, I think the other open source projects are just not very intelligent, they try to make something work and promise features in the future that of course almost never happen, that all already exist fully functional in Torque for many years, it is basically a total no-brainer what engine to use in that case, yet everyone wants to cook their own soup and start all over, leading to eternal development hell.

And regarding C#:
Microsoft was always hostile to open source, they just changed their strategy in fighting it, I would not want to play russian roulette on that and use stuff from them and that was just one argument, the other arguments are that the benefit has yet to be proven, for example I remember testing a Torque built in C# and the performance was indeed by a huge amount better, at least in the small test scene he had, when I loaded it up into my loaded scene, the performance was about 10-20% less. So overall I could not see a benefit in there performance wise.

I would rather improve Torquescript, I saw a post somewhere where a guy improved Torquescript so it ran up to 50% faster, if we can figure that out, that is a far better promise than to gamble with other scripting languages and hoping they do any benefit.
Posts: 27
Joined: Wed Feb 18, 2015 11:53 am
by Monkeychops » Sat Jun 30, 2018 10:23 pm
User avatar
i would like to see both - torquescript improvements and C# as well, as JeffR says.

Torquescript has a lot of benefits... for a start, all the tools are built in it, it's well documented and lots of good examples. It has also been designed around the client-server model and makes it easy to make multiplayer games without needing to understand complex stuff like TCP/UDP or threading.

C# though, in my opinion, is one of the best designed programming languages in existence. It is fast, clean, easy to learn yet goes deep enough for the most hardcore of low-level tweakers. It also works really well cross-platform these days without requiring the developer to think too much about platform differences.
Furthermore - I'd say it has already established itself as the language of choice for the majority of indie game devs. The productivity benefits it gives mean people rarely go back when they start working with it in Unity and both CryEngine 5 and Godot teams have recognised its benefits and invested a lot of effort in C# support because of it.
On top of that, most game dev tutorials and classes these days use Unity (or increasingly Godot) and a lot of universities still teach C# or Java (which is similar).
Making Torque3d more accessible to the masses without needing to learn a quirky, slightly outdated and rough-around-the-edges scripting language will in my view be the key to growing the community, and in turn, getting those PRs flowing in.

Also, don't underestimate just how much stuff you CAN port to different engines. I've ported Unity code from github to different engines before, in C# and TypeScript, although I wouldn't know where to start porting that stuff to TorqueScript because it doesn't have the same OO structure and type safety.
Posts: 490
Joined: Tue Feb 03, 2015 9:50 pm
by Azaezel » Sat Jun 30, 2018 10:31 pm
Will note a couple (hopefully) non-controversial ongoing tasks that folks could jump on in on at any time would be further incorporation of SDL2 to clean up the platform layer by killing off redundancies, and warning cleanups so we've all got less to wade through on that front, if that sparks some notions for folks.
Steering Committee
Steering Committee
Posts: 945
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Sun Jul 01, 2018 3:06 am
@ Monkeychops Yeah, fair points.
It's why it's important to have these discussions.

One thing I'd started messing with during my last few lunch hours at work was this: ... rippedCore

Basically, take the current T3D, and strip it down to just what could be considered the "core" of the engine. Largely as an execrise in figuring what's core and what's a system that sits atop it, but already it's let me spot some structural bits, or include behaviors that could be better.

This is another approach to the clean core, where we can design out the cleaner core "in place" and then enact the structural changes onto the existing repository - doing cleanup, removing cruft, better separating out addons and extra functionality, reorganizing files to make more sense - which would get us to the same endgoal without having to utterly upend and rewrite the entire codebase at once.
Posts: 1500
Joined: Sun Feb 08, 2015 1:51 am
by Duion » Sun Jul 01, 2018 11:00 am
When I work on something I always make a list with points to do and then I work off that list, never doing anything else until the task is completed.

So please stop rebuilding everything and get 4.0 done, the original plan was to have 4 major releases per year for Torque, so we are far behind the schedule. And if we do not have that many contributions, chose one task and get that done, test until it works and release, then do another thing.

The primary task now should be to get some active steering committee members and since you do not want me there I nominate Azaezel for steering commitee.
Site Admin
Posts: 426
Joined: Tue Feb 03, 2015 7:25 pm
by LukasPJ » Sun Jul 01, 2018 8:09 pm
I think we should stop discussing C#, it's a stupid and pointless discussion.

The thing we want/should bring to T3D is an update of the C-Interface. The update I have worked on, aims to help bringing new scripting languages to T3D, as well as improving the tools for writing TorqueScript editors and exporting the API to XML.

In fact, most of the stuff I've worked on, is enabling T3D to export a good documentation of what's going on in the engine, which is a huge benefit to TorqueScript editors.

So the changes are not anti-TorqueScript, they are pro-TorqueScript. As well as pro-any other language.

Furthermore, I honestly would have chosen another language, I would have preferred an easily cross-platform language, like Java. But C# is just easier to work with, in this regard, and since I'm not aiming for providing everyone with their favorite choice of language, but just proving to myself that I can get at least one shitty T3D project done, C# will have to do.

So to summarize: these changes are pro-TorqueScript not compromising it. These changes are not specifically for C#, it is for any language (even a separate C++ library). So discussing whether C# will be harmful is pointless as C# has almost nothing to do with it, and T3D will never be "infiltrated" with C#.
Posts: 27
Joined: Wed Feb 18, 2015 11:53 am
by Monkeychops » Sun Jul 01, 2018 9:21 pm
Yeah, it does seem as though there are a lot of part-finished things on the go I guess it would be nice to see the PBR and such in a stable release before all the core refactoring.
Steering Committee
Steering Committee
Posts: 945
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Mon Jul 02, 2018 3:57 pm
Yeah, it does seem as though there are a lot of part-finished things on the go I guess it would be nice to see the PBR and such in a stable release before all the core refactoring.
The bulk of the effort the past few weeks has been trying to get PBR(and difficulties surrounding it, as described) sorted out. Stuff like the clean core came up in discord and discussions, so a few lunch breaks and the like has been dedicated to looking into what's involved with something like that.

Just because attention has been put into it doesn't mean it's the main focus. It's more about putting together a better idea for the future. :)

@ LukasPJ Yeah, for sure. Ultimately, C# itself isn't the important part, the important part is the c-interface, which opens things up immensely.
Posts: 83
Joined: Tue Jan 10, 2017 11:29 am
by Razer » Mon Jul 02, 2018 11:44 pm
Redoing all again, will push back some years again the engine release.
In that case i don't think we will continue looking up or waiting a little for Torque 3D to catch up with modern rendering and features.

Perhaps the best thing to do is to get the 4.0 release done instead of making the perfect 3D engine code base. There is some other 3D engines that don't have the best code base but at least they are functional and allowed people to make many games.
Steering Committee
Steering Committee
Posts: 945
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Tue Jul 03, 2018 8:11 am
@ Razer Quite possibly, yeah. Doing a full scrapdown/rebuild is not a decision to make lightly as there's a lot of things it impacts, which is why we were doing all this discussion. I appreciate the feedback :)

Over the past couple of days of discussion, and my experiments with the prior-linked T3DStrippedCore stuff lends me to the thought that we could definitely make major overhauls "in-place" by keeping a 'stripped to the core' build like that as a template, so that may be the angle we pursue it on. The main concern with that was that it was too easy to feel tied down to existing stuff that isn't great, or that fixing stuff would be harder than just rewriting it. As it stands with my investigation so far, I don't necessarily thing that holds(for the most part, anyways). I'll keep working on formulating my thesis on that end this week(got people visiting for the holidays this week, so it'll be a bit busy, but hey ;) ) and bring it in here to post what i've found and what I think can be done with that approach.

So, for a WIP Work/Tasks list, since people were asking about that, we've got this currently. It isn't exhaustive, but it's definitely stuff we consider that needs to be done, so it's the perfect list to hammer out first:

  • Verify via threading the GroundCover class(specifically, item placement of cells being populated) that the system operates cleanly and can accept regular "WorkItem" jobs
    [**] If it works: Expand usage to other parts of the engine
    [**] If it fails, fall back to the WIP conversion work of the threading stuff provided by the Life is Feudal guys.
  • Threaded Asset loading/preloading
  • Threaded stock physics subsystem(Bullet and PhysX already thread themselves)
PBR[I'm already working on this]
  • Complete probe projection via zone clustering/filtering
    [**] If it works, no leaks or major flaws visible, do next major bulletpoint subtask
    [**] If it fails to work, due to leaking or undesirable clipping, shift to embedding the distance to the captured pixel in the alpha channel of the specular cubemap, compare there for projection cutoffs
  • Finalize probe-to-probe (and skylight) blending to ensure no overbrightening from overlaps
  • refix editors after removal of global cubemap
  • complete terrain composite map blending via the same methods as other materials
  • Review networking to ensure entities created on a server properly ghost all network-tagged components and component-states to connected clients
  • Review rendering of editing-related elements (SoundComponent emission radius sphere when hitting preview, for example)
  • Create ParticleEmissionComponent based on the SoundComponent as a template (ie, replicates the ParticleEmitterNode values), 'play' bool for simple start/stop handling, preview button to make it fire off in-editor for previewing/testing
  • Create finite state machine system(a StateMachine component already exists, but we may want to utilize the above suggested play/preview aspects)
  • Convert core gameplay classes(Player, vehicle, etc) to internally use Components(or make variants and flag the existing classes as deprecated)
  • Physical Material vs Rendered Material separation(break out the non-visual aspects like sound, footprints, particles, etc into their own class which can be looked up, as opposed to being integrated into a single massive class)
    [**] If it works, (prototyped within at least 2 weeks from start. anything more is likely to reflect too large a shift for folks to deal with when converting): proceed with split features
    [**] If it doesn't, (not done within a reasonable ammount of time): deal with it as-is, and expand any additional features in the singular class
  • Use the visual-only portion as a hook-in base for the node-based shader system
  • Further vulkan/moltenVK future feasability research
General/Ongoing Tasks
  • Warning cleanups
  • Further incorporation of SDL as the core platform layer, further deprecation of per-platform code
Feel free to ask questions, or if possible pick a task and help crack on it. If you wanna help, by all means jump in the discord and poke me or az especially. We'd be more than happy to help get you oriented so you can help us bust down on the task list.
455 posts Page 26 of 46

Who is online

Users browsing this forum: No registered users and 5 guests