[elfprince13]

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]

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]

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]

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]

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]

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.

[odomcl22]

Still struggling with this release. I tried using precompiled, but got an error shown below:

Fatal-ISV: (/Users/jeff/Desktop/Torque3d-development2/Engine/source/platformMac/macFileIO.mm @ 654

Platform::getExecutablePath - Failed to find main.cs!

I cannot find a solution anywhere. So, I want to compile myself. However, I don't know the steps to do that with Xcode. Does anyone have the basic steps?

[JeffR]

It can't even find the main.cs? Very odd. I'm figuring you extracted it and it didn't have any issues with that, right?

Looks like we forgot to make Mac-specific compilation documentation, but really it's not especially different to the windows steps on the wiki:

• Extract to somewhere
• Run cmake
• Point to the apprioriate dirs
• Hit configure
• Let it do it's pop-up
• Put in a name in the App name field
• Hit generate, let it go
• Open the xcode project generated in your target directory
• Do an initial build on the INSTALL project to let it install the template, and then any time after that just compile the game project

I'll see about getting the wiki article for it drafted tomorrow for ya, but that's what you need to do in short-form.

[JeffR]

Quick follow-up on this: but it looks like the binaries are being bit by something in the upload/download process and MacOS is deciding to quarantine the files, which prevents them from working properly. I remember @

Azaezel mentioning one of their guys running into this as well in retrospect, but I'm not sure where the tangle-up would be coming from as the archive is uploaded right off the mac.
Best I can think off-hand is when downloading, because it's not signed and you have to manually OK it with the OS security settings, MacOS is auto-flagging the files for quarantine.

I'll keep poking around to see how we can deal with that so it's a non-issue going forward and then get the binaries re-uploaded once I do.

For the moment, you can either compile it yourself, or you can remove the quarantine attribute by opening terminal, navigating to where the binaries folder is, and typing in:

Code: Select all

xattr -dr com.apple.quarantine Torque3D-310-MacBinaries


Assuming that the extracted folder name from the archive hadn't changed. That should remove the quarantine and let it run normally.

[Azaezel]

Pretty sure our end was due to moving stuff over to the win box then tossing on our private SVN. Still, for the record, what was cropping up (and the apropriate workaround) was:
https://superuser.com/questions/898124/ ... -be-opened not it being unable to find the working directory, which is what that bit with it executing but not able to find main.cs seems to be, unless I'm misinterpreting the report.