Torque 3D 3.10 Released!

26 posts Page 3 of 3
elfprince13
Posts: 22
Joined: Mon Mar 09, 2015 3:41 am
 
by elfprince13 » Mon Feb 27, 2017 11:18 pm
Assets and Modules
The new template will utilize these heavily, but the main advantage is not having to keep tabs on stuff yourself, and not needing to use explicit paths all over the place. This means if something gets reorganized, deleted or renamed, you don’t have a ton of different things exploding left and right because the image or model being referenced no longer exists. It also means it’s easier to use them, as you don’t need to remember the path of an asset, just the module name and asset name if you’re doing stuff manually, and also really easy to install assets and just have it automagically work. The Asset Browser is being introduced to consolidate and standardize how assets are browsed, created and used, so everything should be far more consistent and easy to understand.

Drop a pre-configured package into your directory and refresh the module database and those assets are good to go to be used by everything. No more needing to do a bunch of manual exec’ing of script files and the like to get stuff to appear.

Assets will also cut out a lot of the format finnegaling you need to do now. We’ll be shifting to use Assimp in the backend, so we’ll support a much more broad range of model files that can be imported, not just collada, which is great for the art pipeline and the asset system will deal with the importing and conversion to be used. Same deal for textures. Only have PNGs images? No problem, import them in and it’ll convert them to DDS for you so you don’t have to fuss.

The end goal is to have a very sleek, efficient art pipeline that removes the fussing and just lets you use and keep tabs on the content you introduce.


Is there an explicit issue on GitHub (or a topic here?) where the finer points of this are being worked out?
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Feb 28, 2017 4:38 am
elfprince13 wrote:
Assets and Modules
The new template will utilize these heavily, but the main advantage is not having to keep tabs on stuff yourself, and not needing to use explicit paths all over the place. This means if something gets reorganized, deleted or renamed, you don’t have a ton of different things exploding left and right because the image or model being referenced no longer exists. It also means it’s easier to use them, as you don’t need to remember the path of an asset, just the module name and asset name if you’re doing stuff manually, and also really easy to install assets and just have it automagically work. The Asset Browser is being introduced to consolidate and standardize how assets are browsed, created and used, so everything should be far more consistent and easy to understand.

Drop a pre-configured package into your directory and refresh the module database and those assets are good to go to be used by everything. No more needing to do a bunch of manual exec’ing of script files and the like to get stuff to appear.

Assets will also cut out a lot of the format finnegaling you need to do now. We’ll be shifting to use Assimp in the backend, so we’ll support a much more broad range of model files that can be imported, not just collada, which is great for the art pipeline and the asset system will deal with the importing and conversion to be used. Same deal for textures. Only have PNGs images? No problem, import them in and it’ll convert them to DDS for you so you don’t have to fuss.

The end goal is to have a very sleek, efficient art pipeline that removes the fussing and just lets you use and keep tabs on the content you introduce.


Is there an explicit issue on GitHub (or a topic here?) where the finer points of this are being worked out?


Not yet, but I was going to have a topic up here in the next day or so breaking down the particulars and so people can give ideas and feedback. I'm trying to make it coherent, but in-depth for the short/long term implications, so it's a bit of writing.
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Feb 28, 2017 8:56 pm
Alright, did a post on my workblog(well, 2 posts) going over some of the deets for the new template and the module/assets stuff. Check on it here:
http://forums.torque3d.org/viewtopic.php?f=8&p=7637#p7636 and also the thread for discussing the PR/branch here if you wanted to give some feedback stuffs with testing on the new template: http://forums.torque3d.org/viewtopic.php?f=40&p=7638#p7638
elfprince13
Posts: 22
Joined: Mon Mar 09, 2015 3:41 am
 
by elfprince13 » Wed Mar 01, 2017 9:02 pm
Sorry - I should have been more clear. I was hoping to discuss specifically the asset system and the new important (rather than the module system and the new template broadly). My project (a) currently uses a custom TSShapeLoader plugin and AppMesh subclass, and (b) doesn't have a clear path to integrate with the current asset system, so I want to make sure that the current shape loader architecture will remain suitably flexible and see if we can't figure out how to make the asset system a little bit more flexible as well.
JeffR
Steering Committee
Steering Committee
Posts: 642
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Mar 02, 2017 6:47 am
elfprince13 wrote:Sorry - I should have been more clear. I was hoping to discuss specifically the asset system and the new important (rather than the module system and the new template broadly). My project (a) currently uses a custom TSShapeLoader plugin and AppMesh subclass, and (b) doesn't have a clear path to integrate with the current asset system, so I want to make sure that the current shape loader architecture will remain suitably flexible and see if we can't figure out how to make the asset system a little bit more flexible as well.


Ahh, I see what you mean now.

Yes, I plan to ensure that all current functionality that the shape loader is replicated in asset management(and then some!) in context of being able to modify a shape on/post import, associate materials and animations to a given shape asset and all that jazz. I don't believe it'd be hard at all for you to replicate any customizations you did in the shape and animation asset loading code.

That said, in the near-term, shapes will still operate primarily on the TSShapeLoader/Constructor stuff and go through the resource system internally. Near-term, assets are more about convenient management and tracking/usage of said assets, than a radical redefinition of how they're processed internally. That'd be the long-term goal so things are cleaner and more consistent, but the near-term shouldn't see any major waves on the backend side of things.

I can give you a specific example case in my RnD brach stuff if you're curious, but as said, the ShapeAsset, for example, is currently more about tracking/usage management than a new paradigm in how the resources are actually loaded in context of the engine.
If there's any particular things you did/plan to do you're thinking specifically, lemme know and we can talk more in-depth on the particulars, but I'm 100% confident we'll be able to make it work with minimal fuss going forward.
elfprince13
Posts: 22
Joined: Mon Mar 09, 2015 3:41 am
 
by elfprince13 » Sat Mar 04, 2017 4:30 am
Glad to hear the AppMesh / TSShapeLoader stuff will stay pretty much intact. I opened an issue here to jumpstart the discussion around how I'd like to see the flexibility of the asset manager expanded.
26 posts Page 3 of 3

Who is online

Users browsing this forum: No registered users and 1 guest