Hi Amazon ,
I saw , many game engine that We Can Import Assets [ JPG, TIF , DDS , Raw , PSD ] WITHOUT Plugins(Tools).
NOW, Is Possible, We Import Import Assets [ JPG, TIF , DDS , Raw , PSD ] WITHOUT Plugins In the Lumberyard???
IF NO , Please Add a feature that We can Import Import Assets [ JPG, TIF , DDS , Raw , PSD ] WITHOUT Plugins(CryTIF ,Like as FBX Importer without plugin import models) in the Lumberyard 1.7.
thanks a lot
Hello @AhmadKarami, I have had success with manually importing texture files into my projects, (the diffuse, spec and ddna), without needing to use the CryTiff plugin. As long as they are in the correct format (Gloss map in the normal’s alpha channel), I was able to place the files by hand into my projects texture folder, and then select them in the material editor in the engine. I have had luck using .PNG and .TIFF files.
However, for other texture types, such as light projectors, I think you have to use the CryTiff import, as it doesnt work without it.
Hope this helps!
so I had to register on this forum just so I can voice my concern as well:
I agree with OP, a stand alone import would be nice instead of trying to “hack” with the RC.exe. You already have the code, please make it save the intermediate work (processed TIF) before dumping it to DDS (which should be triggered by editor/rc interaction anyways). I looked at the command line switches for RC.exe and there wasn’t one to indicate where to save processed TIF. Add that, and a Gimp plugin, or any other graphics package can be done fairly easily.
You shouldn’t enforce usage of tools such as Photoshop, Maya and Max, this is just bad coding juju, unless of course you have a contract of sorts with them. I understand that your business model is AWS, which I 'm glad to and will support, but not the first ones unless I go “indi” with that. So, yes the “software contract” should be mediated through a “file format” and not a particular software lock. Think TIF & FBX, not PS & Max.
I had an Adobe CC subscription, but I’m not about to re-sub for it if I don’t know if I’m going to stick with LMBRyd when it supposed to be free pre-deployment.
Also look at Twitch Creative category, 99% of people there use Unity to do their work. I don’t think I seen a singe LMBRyd or a Cry user in there in a past 2 weeks of me lurking in their GameDev category. Add just this bit (make CryTIF a standalone) to get some traction with community. One common theme I saw from them - Asset Import sucks in Cry/LMBRyd. This should be a priority item for 1.7.
Advertise that it now has a “state of the art assets manager” with a stand alone importers, and can now be used with virtually anything, OpenSource software as well (Blender, Gimp, etc), and even MS Paint for those who love a little pain, and you’ll get some hobbyist start to line up, not just the Star Citizen.
Thank you, and I hope that you may consider my 2 cents of an input & don’t think that it’s overly critical.
@SolairePhantom @AhmadKarami It is pretty straight forward to import textures into LY without needing photoshop. All you need to do is select the textures, right click and select RC Open Image. Then select your preset and resolution and click Ok. It will then create an exportsettings file that you copy into your project with the texture. Just make sure you follow the file name suffix listed here http://docs.aws.amazon.com/lumberyard/latest/userguide/mat-texture-types.html.
Just to follow up on this, one of the first things Lumberyard devs did is to make it so it supports texture formats besides TIFF, and be able to do so without the plugin.
The process known as the Asset Processor is monitoring for changes in your assets folders (including changes to images) and it will process and make available to use in the editor any formats that it currently supports, even without using Photoshop. As long as the file is one of the compatible types (which include BMP, JPG, TGA, TIF, GIF and PNG), merely placing it in the project’s folder will cause it to be compiled into a DDS file by the Asset Processor and cause it to show up for use.
If you want to change your settings (for example, change the preset), you can right click on the file and select “RC Open Image” to see the same dialog as you would see if you were to use the Phototoshop Plugin to save the file as a TIF (except without having to use the photoshop plugin).
Note that this option should only show up if you have selected the “RC Shell Extensions” addon in the Setup Assistant in the optional extensions page, which is what edits the registry to make those options show up
Technical note for the curious: Under the hood, this is simply running RC.EXE with the name of the file and /userdialog=1 command line option - which is also what the Photoshop Plugin does whenever you save. The Photoshop plugin does not acutally show that dialog itself, it merely invokes RC.EXE with the appropriate option after saving, and that’s what the shell extension does, too.
Similarly, as the FBX pipeline comes online (more and more options are supported with each release), it is possible to use the in-editor configuration tool (FBX importer window) to configure how the pipeline imports the FBX.
Thank you for replying to my comment. @EricRLA, I tried what you described, and it didn’t work. Maybe I missed something.
@Vektuz, yes, by placing a TIF file directly into directory, it does pick it up, but, I don’t get the optimizations & filters done by RC and by Asset Processor.
I did record a short video that demonstrates this, including Asset Processor ignoring the .exportsettings associated with a given texture. Please take a look at it: video explaining situation
Please let me know if I misunderstood the way it was supposed to work, or if there are some improvements in order that we could look forward to with upcoming updates to LY.
Thank you as always, Solaire
Just an update on this topic.
I usually don’t program in C++, I do prefer Common Lisp, but in order to get back into C++, i just ended up patching ImageCompiler.cpp code starting at a line #1783 to produce the “intermediate” TIFF with filters applied to it as i wanted.
code notes:
checks for “user dialog” mode in order to not interfere with any batch operation modes
is triggered on “generate output” button push and generated right after DDS is generated
name of a generated TIFF as follows: <path_of_original_texture>**<my_prefix>_**.
If I could have a permission to post my patched code here or if I can submit it to a LY dev, please let me know, so it can be contributed/integrated into LY project. Code change is “as is”, no credit required.
Thanks!
This is super interesting to me, actually. While we won’t be able to use any code you post directly I would love to get some more information, such as what you changed exactly and for what reasons specifically.
First though, I’d like to make sure we are talking about the same things. What do you mean by “filters”? Do you mean the preset compiler settings (so like ‘Albedo’ versus ‘Reflectance’?)
The “.exportsettings” file is supposed to be used whenever asset processor crunches the file. AssetProcessor currently crunches textures by feeding them to RC.EXE, which itself is then supposed to read the .ExportSettings file in order to choose what to do with the file. The .exportsettings file is supposed to be read by RC.EXE and its supposed to override whatever presets would normally be used by default if there was no such file.
The photoshop plugin does not save any such information into the file, it just saves the TIF file normally, and then it launches RC.EXE /userdialog=1 (FILENAME) showing the same GUI.
Are these filters you mention in your post something more than than just the selection of presets and other stuff that is in the RC.EXE user dialog GUI? Maybe something beyond just a preset or other settings? What kind of files is it producing / what is the expected output?
The current expected behavior that I’m aware of is:
any time the .exportsettings OR the image itself changes, Asset Processor detects this and sends the image file to RC.EXE
RC.EXE opens the file and crunches it into DDS files. It obeys the settings in the .ExportSettings file, and places the result in the asset cache (dev/cache/…) for the game to use. No other files are created, since we don’t like to modify your source files without your permission / user input during asset crunching (since it can happen in the background, and the files may be read-only / checked into perforce / on a network drive)
Running RC.EXE on the file with /userdialog=1 causes it to show you a GUI that lets you change the export settings. Clicking “OK” on the GUI is supposed to cause it to overwrite the .exportsettings file. When this happens, as in the first step above, asset processor is supposed to notice the change and send the file to RC.EXE again for processing, this time with the new settings.
Maybe there is a piece of the puzzle I am missing. I appreciate the time you’re taking to look at this, and I want to to work in the right way for everyone.
EDIT: I viewed the video. I see some interesting things here, which we need to think about.
The expected workflow is that you modify your images in-place inside your folder. You’re not required to copy them from your desktop into your source folder every time you need to. (But you can if you want to)
The “preview” image that shows in the material browser prefers showing your source TIF file if possible for preview purposes. We could switch it to showing whats in the DDS file instead. So the reason you’re not seeing the highpass filter applied is because it is applied to the output DDS, but not your source file since we really don’t want to modify your source files.
The DDS file that is output into the cache should have the highpass filter applied. The reason it is split into multiple files is actually for reasons of texture streaming. The engine loads the smallest MIP level(s) first depending on settings, and then loads the remaining detail levels in as you move around the level, trying to keep the highest quality textures visible even if you have limited memory. RC.EXE makes this simpler by splitting the files. the .dds file has the lowest mip(s) in it, and the header, wheras the other dds files have bigger and bigger MIP levels (but not header or anything).
In other words, its probably actually working as you expect except for the preview window.
The actual dds the game actually uses should have the high pass filter applied, because the DDS generated in the cache were made with that option in the exportsettings file.
You don’t have to apply your high pass filter yourself, as long as you put the source file in the source folder with its export settings. In fact, the recommended workflow is to just keep the TIF open in your favorite DCC tool and every time you hit save/export it should just update automatically in the game as well as the editor without you having to type anything or do anything. (Because the Asset Processor will auto process).
I’ll look into that preview window. It could be confusing that its showing the actual source file when available instead of showing the output. Another possibility is that the editor is using the source file for the 3d renderer, when it should be using the processed DDS (which should include the high pass filter).
Also, if you run the runtime (ie, SamplesProjectLauncher.exe) on your terrain, the engine ONLY has access to the assets in your cache, so it definitely should be using the processed DDS, which should include the filter. If its wrong there too, it probably means RC.EXE is not applying the filter when it should. We will investigate.
Thanks for the info. We intentionally do not want to modify your source files, as this may cause a loss of information. When you apply filters it commonly reduces the amount of information in an image, and strips you of the option to remove those filters later and apply different filters. In addition, the Asset Processor pipeline runs in the background, automatically, and you may be dealing with files that are in use by applications or even checked into a source control repository, or being processed on a “nightly build” server that auto-generates a build of your game every night.
In all of those cases you really don’t want your “originals” to be modified.
When I say “Baked into” DDS, what I mean is that it takes the original source image, loads it into memory, then all the selected filters are applied, and other settings are also applied - for example, image compression preferences, filters, downscaling, splitting for source, and doing any kind of pixel conversions that the video card needs (Various hardware such as mobile devices have differing needs for the images) … all of that is computed and the the resulting DDS saved has all of them already applied so that when the game runtime loads them, it does not need to do any of the work - the image is ready to use.
Thus it is not necessary to modify the user’s original data and we don’t suffer data loss.
Ideally the person has the game running (or the editor) on one screen, and the Painting tool (Krita or Photoshop or Gimp or whatever) running on the other, and they are editing the actual source image file, so everytime they hit save or export in their DCC tool, they can see it update immediately, without having to use file browsers or drag files around. Folks tend to save the image as they work on it a lot more often than you change its presets, so its convenient to configure the preset once, then just from that point on keep saving over the TIF (or PNG or BMP) and see it update live.
@Vektuz, yes, by “filters” I mean the presets.
Ok, looks like the method you described works - by having .exportsettings file, the confusing part was that the original texture was not modified. Very interesting. Does it actually get “baked into” .DDS files?
Nevertheless, the code I added was as follows (not needed anymore):
/* mod to ImageCompiler.cpp at ~ #1783 to produce "intermediate" TIFF file */
// destination
if (!SaveOutput(m_pFinalImage, pExt, sOutputFileName.c_str()))
{
RCLogError("CImageCompiler::SaveOutput() failed for '%s'", sOutputFileName.c_str());
return false;
}
/* START mod: save intermediate TIFF file with transformations :by SolairePhantom, 1/12/2017*/
const bool bDialog = m_CC.config->GetAsBool("userdialog", false, true);
if (bDialog) {
string sOutTiff = PathHelpers::AddSeparator(PathHelpers::GetDirectory(sOutputFileName)) + string("ex_") + PathHelpers::RemoveExtension(PathHelpers::GetFilename(sOutputFileName)) + szExtendFileName + string(".tiff");
if (!ImageTIFF::SaveByUsingTIFFSaver(sOutTiff, GetSettingsFile(sOutputFileName.c_str()).c_str(), &m_Props, m_pFinalImage))
{
RCLogError("CImageCompiler::SaveAsTIFF() failed");
return false;
}
RCLog("Generated TIFF as well: %s", sOutTiff.c_str());
}
/* END mod: save intermediate TIFF file with transformations :by SolairePhantom, 1/12/2017*/
Thanks!