Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Alloy Physical Shader Framework by RUST LTD.

Discussion in 'Assets and Asset Store' started by xenius, Nov 20, 2013.

Thread Status:
Not open for further replies.
  1. Tanshaydar

    Tanshaydar

    Joined:
    Apr 20, 2011
    Posts:
    33
    Hi again;
    When I try to change shader of an object (on specific objects to be exact) I got this error:
    Code (csharp):
    1. ArgumentException: An element with the same key already exists in the dictionary.
    2. System.Collections.Generic.Dictionary`2[System.String,UnityEditor.SerializedProperty].Add (System.String key, UnityEditor.SerializedProperty value) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:404)
    3. Alloy.AlloyInspectorBase.AddPropsFromArray (UnityEditor.SerializedProperty props) (at Assets/Alloy/Editor/AlloyInspectorBase.cs:141)
    4. Alloy.AlloyInspectorBase.InitAllProps () (at Assets/Alloy/Editor/AlloyInspectorBase.cs:126)
    5. Alloy.AlloyInspectorBase.OnInspectorGUI () (at Assets/Alloy/Editor/AlloyInspectorBase.cs:79)
    6. UnityEditor.InspectorWindow.DrawEditors (Boolean isRepaintEvent, UnityEditor.Editor[] editors, Boolean eyeDropperDirty) (at C:/BuildAgent/work/d3d49558e4d408f4/Editor/Mono/Inspector/InspectorWindow.cs:850)
    and shader changes but there is no panel for Alloy settings.
     
  2. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Tanshaydar: I've seen this before. It seems to be an intermittent bug caused by the 'junk' data that Unity keeps around in the material. Quick q: are you using the latest version (2.02)?

    Anywho, the only way around this is to delete your current material, and create a new one. Sometimes, data gets help onto from before the material was set to being an Alloy material, and the custom editor messes up. We're working on a smarter fix!

    NINJA EDIT: I just checked with our editor coder. This _should_ be fixed in 2.02 already. Can you DL the update, then reimport the ShadersAndEditors sub-package. Tell me if that fixes things.
     
    Last edited: Mar 25, 2014
  3. Tanshaydar

    Tanshaydar

    Joined:
    Apr 20, 2011
    Posts:
    33
    Yes I am using latest version. To make sure, I updated it both in my personal computer and in the office. I had this issue a few times before but they were magically solved along the way, so I figured that Unity keeps some kind of a cache preventing the change. However, last few changes never took place. I change the shader to Alloy one, but I can't open the panel to settings; but if I set them to Unity's build in shaders, they work :/ Some models need to touch the eye so I need them to be Alloy shader :D

    I deleted the shader folder and now re-importing the package. Though that will take some time. I am one of those unlucky people who had 28 hours to import all :D Hopefully that will solve the issue. If not, I'll create new materials to make them work.
     
  4. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Tanshaydar: Question for you. When you create a new material, are you duplicating a material in your project view, then changing it. Or are you going into the project view and clicking Create -> Material?
     
  5. Tanshaydar

    Tanshaydar

    Joined:
    Apr 20, 2011
    Posts:
    33
    Finished re-importing, no change.
    I delete existing material and create new material with Create -> Material, and assign Alloy to it. It works in the first time, then when I get back to it for settings, same thing happens.
     
  6. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Tanshaydar: what on earth... can you package up just a testing scene, material into a zip, upload it to dropbox, and send me a link to DL in a PM? I'd like to take a look at it and see what's going on.
     
  7. Tanshaydar

    Tanshaydar

    Joined:
    Apr 20, 2011
    Posts:
    33
    I found a workaround for this.
    I need to delete the material completely, and then re-assign textures, and then re-assign the material to model. It's not handy but it works.
     
  8. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Tanshaydar: Yes! That's what I was trying to communicate. The garbage-data coming along for the ride is in the material file itself (the Unity material is basically just a wrapped database file that you don't have good access to). When I've run into this problem before, I've always had to simply delete the old material and create a new one. Hopefully in the future we'll have a more elegant solution for this. Ah.. the joys of generalized editor systems...
     
  9. Tanshaydar

    Tanshaydar

    Joined:
    Apr 20, 2011
    Posts:
    33
    That data is a complete headache. It does the same for hinge joints too. Hopefully Unity will solve it.
    Anyway, thanks for the help, case solved, back to work, and thanks for creating such a wonderful pack :)
     
  10. GXMark

    GXMark

    Joined:
    Oct 13, 2012
    Posts:
    514
    This problem is now solved
     
  11. Wilbert-Blom

    Wilbert-Blom

    Joined:
    Aug 13, 2011
    Posts:
    109
    I've just bought Alloy and want to try it out but importing the package is taking VERY long!
    It's already 2 hours and the process bar is at about 50%. If it's going take this long everytime I want to use Alloy it is unworkable.
    I'm using a QuadCore i7-2600K 3.4GHz with 8 GB RAM on Windows 7 64bit.
    I'm importing from a SSD-disk and so is the project. Should all be fast enough ?

    Regards,
    Wilbert Blom
     
  12. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Juzerneem: Right now, the unity system for importing and compiling shaders has two major problems:
    - it is a single process, that is single threaded, so it's at max going to max out a single thread on your cpu
    - it's compiling every friggin permutation for _every_ damn platform unity can run on, even if its not a logical one for the set (like mobile, sm2, etc).

    In the next unity update (4.5), problem #2 is solved, as they only compile now for your current build target. This _massively_ speeds up the import process.
    In Unity 5.0 (apparently), problem #1 is also solved, as it dispatches multiple processes, one-per-thread to compile things, making it hugely faster.

    Until then, the way I often work, is I keep a project dir around with Alloy imported, with nothing else in it, on the machine I work on, and simply duplicate that dir and rename it for creating new projects. I know its not ideal, but this is the limitation _any_ large multi-compile using shader system currently faces.

    Apologies on it wasting your time, tis a limitation of the engine that we're just waiting for to be dealt with.
     
  13. OneShotGG

    OneShotGG

    Joined:
    Nov 16, 2012
    Posts:
    225
    I am wondering if y'all are going to do away with the "map packing" in future releases.

    After playing around with ue4's pbr pipeline it made me realize how stiff and un-flexible alloy currently is in regards to procedural texturing.

    I appreciate everything you do to make alloy and substance designer work together but limiting the use of substances that can be changed at runtime is disappointing.

    For example I would like to have control of roughness at run time so I can use a position map to add wetness based on the collision height of a water plane.

    Something that is simple to set up in sd4 but impossible to do when the roughness is packed away.

    Also, your sd4 shader causes a bunch of weird artifacting that the built in shader does not have. Just a heads up.
     
    Last edited: Mar 28, 2014
  14. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @OneShotGG: Thanks for the great questions! I'll try to answer them in an orderly a way as possible (as there's a bunch of factors at play).

    First, regarding the map packing, it was a choice we made based on the texture-sampler limits within SM3.0 (something we fight with all the time). UE4 (and SD4 for that matter) have the benefit of being DX10/SM4 by default, so their ceiling on the number of unique texture samplers is much higher. Down here in DX9-land, there's a fairly strict limit, enough so that our most complex shaders come right up to the limit.

    Now in terms of roughness, I'm of two minds on this. The first thing is that generally, one wants to use corrected-roughness whenever possible to avoid specular aliasing (hence why we built the texture packer, that also does some complex filtering on the roughness map's mips when you plug in a normal map). Now obviously, with dynamic effects such as making things wet, this sort of thing isn't possible, so one would want maximum flexibility (so that having a dynamic substance recalc in real-time wouldn't require re-processing 4 channels when only one is changing).

    At the moment, to add that sort of flexibility would _explode_ the shader permutations we have currently, and be a nightmare to manage/work with due to Unity 4.X's current multicompile-shader-nonsense (see my earlier post). _However_, as we're moving into the planning phase for how Alloy will function in Unity 5, we're very much open to suggestions/requests/needs from the community on what sorts of togglable options would be wanted by folks.

    Regarding that, I have a couple questions for you:

    Considering the texture sample limit issues, would you be willing to give up feature-combinations to be able to have the physical parameter texture inputs (metallic, occ, spec, roughness) be separate textures? Note that that's the equivalent of giving up say... masked incandescence and textured rim on a given material.

    Having separate textures for the inputs in that case would mean using full RGB textures for that channel (there's no such thing as a 1-channel texture on a gpu in DX9). Do you feel comfortable with the data bloat that would entail/do you feel having that control outweighs the waste of using a full RGB texture for a black and white data channel?

    Note that while I don't recommend it, the built-in packer doesn't _have_ to be used. You can very much pack your data maps into an output texture right in SD4, and have whatever dynamics you require piping in your individual channels. I just did so on a recent demo we did, where we changing bits of the metallic and roughness based on input parameters.

    Lastly, I'd like to see the artifacts you're encountering in the SD4 preview shader. Shoot me an email at alloy@rustltd.com and I'd be happy to take a look and see whats going on with it.

    Thanks! Hope this was helpful for you.
     
  15. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Everyone: Hey guys! I just wanted to show you guys some of the progress we've made in putting together a Skin Shader for Alloy! Details in this blogpost here: http://www.alloy.rustltd.com/?page=blog&post=alloy-skin-shader

    I'll be pushing an update with a beta-form of the shader (no fancy editors, some params still up in the air), this weekend! When that happens, I'll throw up another little how-to on how to use it!
     
  16. OneShotGG

    OneShotGG

    Joined:
    Nov 16, 2012
    Posts:
    225
    Wait, is alloy only dx 9?

    If so why and will it always be stuck in dx9 land? Not to sound like an ass but dx 12 is coming up pretty quick...lol. IFAIK unity is dx 11 and sm5 currently.

    So if you were using dx 11/sm5 like ue4 you would have the shader overhead you need?

    To answer your question I would like it to work like in ue4 (minus the material editor). Heck it would be nice for alloy to be 100% substance compatible too.

    What I mean is that I place a substance on a mesh, select the alloy shader I want it to use in the drop down and have it auto propagate like it does with default shaders, or skyshop shaders. No packing, just simplicity. I am no mobile developer so being dx11 and sm5 would be great too.
     
    Last edited: Mar 29, 2014
  17. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @OneShotGG:

    Unity has two modes, DX9 and DX11. What this means is, if you want to develop a shader set that's cross-platform (currently), one has to use DX9 constraints. Unity only even has DX11-mode due to WindowsPhone8 needing it from my understanding.

    To fully utilize DX11's parameter/input ceiling, we would have had to make it a DX11-only product, which as you might imagine, would be a fairly small audience.

    Once Unity5 is out, it might be easier to mix-match a bit more, allowing shaders to go into SM5/DX11 territory easier when needed. We should know more about that in the coming months.

    Of note as well, UE4 has had to deal with its own data-limitations, as they lack (based on the paper they released), any input for Specular intensity/f0 in thier material setup. So all non-metals use the same f0. Wood=cloth=stone=etc. Rather odd, but i assume this was done to fit everything through their layered material setup before hitting DX10's texture input limit.

    Anywho, hope that clears things up for you.

    -Anton
     
  18. KRGraphics

    KRGraphics

    Joined:
    Jan 5, 2010
    Posts:
    4,458
    Very impressive :)... keep up the good work on this :)
     
  19. OneShotGG

    OneShotGG

    Joined:
    Nov 16, 2012
    Posts:
    225
    Ugh, that's what I was afraid of. Thanks for explaining. Unity is a great engine but it, and some of its users, seem to be stuck in the 2000s. It is ludicrous that dx9 still has such a stranglehold on development in 2014.


    I completely understand why y'all target dx9 given the circumstances. Just disappointing as I was going to go completely pbr for our current project. No biggie I will just use skyshop shaders for our characters and alloy for everything else.

    Maybe by 2020 dx 9 will finally be dead for good? ...lol

    From my experience ue4s specular channel works just like yalls specularity (aka it lets you adjust speculiarity of non- metals). They even explain it in one of their tutorials.
     
    Last edited: Mar 29, 2014
  20. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @OneShotGG: You want to blame someone for the SM3.0 bullshit? Blame Apple, for now including stock a more advanced version of OpenGL as standard until Mavericks. Cross-platform focused folks have been held to supporting SM3.0 because its the latest thing that can be counted on to be resident on the machine (for things like say...webplayer games). I'm sure Mavericks only finally has GL4 on it because OpenGLES on mobile was about to surpass the feature-set that was present on OSX...

    Good to hear that Epic saw the light and added spec back in. Their PBR paper from about a year ago that we used for some of our research totally omitted it, and it looked like they were going to roll without it, which seemed just... maddening to me.
     
  21. KRGraphics

    KRGraphics

    Joined:
    Jan 5, 2010
    Posts:
    4,458
    Hey Xenius, I was looking at the skin shader in the blog and I was wondering about layers for tattoos. Will it be treated like a subdermal map, such as veins under the skin, or follicles. Also how is the scattering handled (I agree it is a pain in the ass to tune? Will I have to bake out a scatter map? Or could I get away with painting it?

    And my final question, will you guys be integrating a version of the shader for substance designer/painter? Would make life so much easier.
     
  22. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Neptune Imaging:

    Right now, the beta shader is just a standard skin shader (though it has an SSS mask where the Metallic channel used to be on the packed map, for masking out a dielectric area). We'll eventually expand this into a fuller set with tattoo/paint/etc. options, but we want to make sure the core params are working well, hence why we're releasing a beta/unfinished version first.

    You will need a transmission map of some sort as well (blue channel). For that you can either use Knald, or the backwards-occlusion-map-trick (which i used for this example).

    As for SD4, not sure yet honestly. SD4 still isn't gamma-correct (we're manually correcting in the shader), so doing anything more complex right now for it will probably wait until they change that.
     
  23. KRGraphics

    KRGraphics

    Joined:
    Jan 5, 2010
    Posts:
    4,458
    good to know. I'll keep an eye on this one. I'll stick to manual methods on the skin.
     
  24. Steve-Tack

    Steve-Tack

    Joined:
    Mar 12, 2013
    Posts:
    1,240
    I've got two questions about Alloy:

    1) In what ways is it different from Marmoset SkyShop? It seems very similar.
    2) In what ways will it still be relevant in future versions of Unity, given that Unity 5 and beyond will have physically-based shading built in?

    Thanks!
     
  25. dixitalgorismi

    dixitalgorismi

    Joined:
    Aug 6, 2013
    Posts:
    30
    Hi! I just bought Alloy and installed the package (following the instructions about linear and HDR on the cam). The problem is that none of the core shaders except the skin shader seems to work - because they can't compile. I get the typical "Material doesn't have a float or property _xy" in the error log. The attributes are _color for example... So I opened the compiled shader and there it is:

    // surface shader with errors was here
    Pass { }
    /*// errors analysing surface function 'AlloyStandardSurf':
    // Unterminated #ifndef
    */
    #LINE 49

    }

    I'm on OSX Mavericks, Macbook Pro Retina Late 2013 with Iris Pro, Unity Pro 4.3.4, Alloy version from today. Any idea?

    P.S.: Also, the unity package for Alloy unpacks the AssetsStoreTools.
     
    Last edited: Mar 31, 2014
  26. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Dixitalgorismi: Egads! Something has gone awry, working on fixing it now!!
     
  27. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Dixitalgorismi (and everyone else): It looks like in adding some header info for the Skin Shader, we left a hanging goof in there. I'm recompiling now and getting an emergency update in aaaaaaaas we speak. Many apologies to anyone this has inconvenienced! This is why Anton shouldn't push updates at 1 in the morning...

    Thanks so much for catching this! It appears that my copy of the non-skin shaders hadn't fully recompiled (due to Unity caching shenanigans) so I didn't catch this. I promise, we're usually much more careful about these things!
     
  28. dixitalgorismi

    dixitalgorismi

    Joined:
    Aug 6, 2013
    Posts:
    30
    Hey, cool! I'm happy this isn't something on my side. Eager to use Alloy :)
     
  29. cygnusprojects

    cygnusprojects

    Joined:
    Mar 13, 2011
    Posts:
    766
    Just bought this asset while it's in sale ... very disappointing to see all materials turn out to be pink :( I guess it has something to do with the issue Dixitalgorismi just reported?
     
  30. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Cygnus: Yes! Again, soooo sorry. My recompilation is almost done, and I'm getting it pushed back up to to the asset store right after! Don't worry, this will be fixed within the next 2 hours!
     
  31. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    HOTFIX UPDATE 2.0.4 IS LIVE

    Please download it immediately if you downloaded Alloy in the past 24 hours!!

    If you'd like to know what happened, I'd like to explain the problem, as its something to look out for if you're tinkering with your own complex shader sets. Basically Alloy, relies on a bunch of centralized header files to help manage all of our variants/modes. This is wonderful, except for one little thing. When you change a header file, it doesn't auto-recompile shaders dependent on it. What happened with 2.0.3 is that we added a couple things for the Beta skin shader, and I had _thought_ that I had fully recompiled the whole set, but I hadn't, which means we missed a small bug that borked basically everything _but_ the skin shader. All of the other shaders in my testing project were still cached from compiling with the old headers, so I didn't catch the error until @Cygnusprojects posted above.

    Thankfully it was a 3 line fix.

    Again, apologies for this, we are as a rule far more thorough than this when doing testing. We just wanted to get the beta skin shader into the set in time for this sale, as a thank-you to all our current customers, so you guys have something new and cool to play with!

    Happy Shading,
    Anton

    *Ninja-edit* If you download 2.0.4, you should only need to reimport the ShadersAndEditors package to fix this bug. If they're still pink after you do this, right click the shaders dir in the project and click 'reimport' to make sure the cached compiled shaders are replaced.
     
    Last edited: Mar 31, 2014
  32. Korindian

    Korindian

    Joined:
    Jun 25, 2013
    Posts:
    584
    I think the Alloy team may have missed this post. Although I did see xenius's previous post in the middle of page 12 which addressed question 2, I'm still wondering if the features that Alloy may provide for Unity 5 will be worth $62.50 (sale price) to $125 more than what Unity will be providing itself with Unity 5.

    I've been keeping my eye on Alloy for my next project, but I need a little more convincing from the Alloy team that I'll be getting more features over Unity 5's included PBS system to justify a purchase.

    Thanks for your time!
     
  33. cygnusprojects

    cygnusprojects

    Joined:
    Mar 13, 2011
    Posts:
    766
    @xenius: everythings is peachy now, thanks for the hotfix! Time to play with this beauty.
     
  34. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Korindian Sorry to not respond to you sooner. The 2.0.3 bug problem I created has been a bit of a stressy-mess to fix the past couple hours.

    In regards to the difference between Skyshop in Alloy:
    Skyshop is an editor extension for creating and managing HDR panoramic sky probes for doing IBL (that's awesome), that also ships with a bunch of shaders that are essentially extensions/modifications/expansions on the standard set of shaders that come with Unity.

    Alloy is a Physically-Based Shading system (if you're unclear on what that means/provides, this forum thread is full of my explanations/descriptions of that). It also supports the output that Skyshop generates, as we thinks the folks at Marmoset are awesome, and that they've created a wonderful product.

    You're right in seeing that on page 12 I laid out the differences (as I know them to be) between our offering and what UT has revealed thus far about their PBR system for Unity5. To further elaborate the differences listed there, we're a continuously-in-development product that will be continuing to add more features and variants in the lead up to, and after the U5 update. The skin beta shader that we just added to the set is an example of that, which will be being filled out into a fuller SubsurfaceScattering set, with variants for foliage, and more complex character options. I am _sure_ that U5's PBR system will be a wonderful solid foundation for folks to start off with, but as we've seen in prior UT releases, their goal has been to hit the base needs for folks, not to provide an incredibly deep, feature-rich set. Alloy is here for folks who like the UE4/SD4 style PBR channel layout, and who want a more extensive set of options for their shaders.

    Let me know if you have any more specific questions about our set! And apologies again for missing your questions earlier this morning.
    -Anton
     
  35. Korindian

    Korindian

    Joined:
    Jun 25, 2013
    Posts:
    584
    Actually it wasn't my post... I was quoting Steve Tack's post, so no problem :)

    Your explanation convinced me and I'll be picking up Alloy later today. I do use Substance Designer 4 and like that Alloy will be continuously supported with new features and shaders. I also like that you guys make it a point to integrate with other assets on the Asset Store. Thanks for the quick response!
     
  36. Steve-Tack

    Steve-Tack

    Joined:
    Mar 12, 2013
    Posts:
    1,240
    Yeah, that was me. :)

    @xenius thanks for your reply, and I did check out page 12, which answered a lot of my questions. I'll likely be picking up Alloy, if only to understand the differences in workflow and rendering results.

    Some of the terminology in the world of IBL/PBR is a bit baffling. Like SkyShop shaders use gloss maps to define how rough or smooth a surface is, which would seem to be similar to a "roughness" map as Alloy calls it. Isn't that a big part of physically-based rendering (in both cases)?

    Marmoset has one of the top Google hits on "physically based rendering":
    https://www.marmoset.co/toolbag/learn/pbr-theory

    Anyway, I do realize that one of the key differences is that Alloy has a "metal" map for how metallic a surface it is, which isn't how SkyShop does it.
     
  37. lod3

    lod3

    Joined:
    Mar 21, 2012
    Posts:
    671
    Ah, awesome. Was going to make a post, but will try this fix tonight. Thanks!


     
  38. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @SteveTack Hi Steve!

    I agree that a lot of the PBR terminology is confusing, because we have several words for describing... basically the same darn thing, as almost every implementation of it has striven to find/make their own most conceptually clean way of describing things. Everyone also seems to be using very different channel setups. Some shaders use gloss/glossiness/smoothness, which is a map thats:

    Rough/Matte(0) to Smooth/Glossy(1)

    others(like us, SD4, UE4, Disney, etc) use a roughness map which is

    Smooth(0) to Rough(1)

    There's a complex matrix of workflow/conceptual/implementation reasons why these differences exist, but they can all be considered to be a type of 'microsurface' map, in that they represent the microsurface texture of a material that determines how light bounces off it.

    Anywho, to expand upon the Skyshop Shaders vs. Alloy thing, it isn't just about map differences. The most important thing to understand is that PBR-style shaders are doing lighting math in a completely different, significantly more accurate and consistent, but also more expensive, way to the old blinn-phong model (all of unitys standard shaders, skyshop's etc.) Plus, one tends to have to build an entire framework around either doing PBR, or not doing it. The reason skyshop's shaders aren't PBR (while Toolbag2 is), is likely the result of PBR being a non-starter on mobile right now (unless you're using a TegraK1 :p)

    Anywho, I hope this helps you make sense of all of this. I'm getting the feeling that with the influx of new customers, I should think about doing a live-streamed demo/introduction to things on Twitch or something. Any of you feel like that might be useful?

    -Anton
     
  39. Steve-Tack

    Steve-Tack

    Joined:
    Mar 12, 2013
    Posts:
    1,240
    Ah, now that's a great answer. Thanks for the extra detail! I would find any additional information useful (in whatever form).
     
  40. dixitalgorismi

    dixitalgorismi

    Joined:
    Aug 6, 2013
    Posts:
    30
    I just tried the Substance Designer 4 integration. It's not working. It fails silently and just shows nothing in the 3d view when I switch to the alloy shader. No cube, no custom geo - nothing. Did anyone use this successfully on a macbook retina (with a iris pro)?
     
  41. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Dixitalgorismi: Which engine are you using inside SD4? DX9/DX10/SSE?

    *ninja edit: I'm asking the Allegorithmic folks about it. They've had some issues in the past with the terrible ogl/driver support that plagues osx. This might be related. I'll see if i can get more info. Either way, running SD4 on an integrated GPU is going to be a spotty experience all around. The intel 5200 just might not be able to handle the shader correctly.
     
    Last edited: Apr 1, 2014
  42. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    $AlloySkinImage.jpg

    Also, in case you didn't see the post a page back or so, there's a new shader in the pack, still very-beta-stage, for doing character skin. I'd love to hear back from folks trying it out on your character models (don't be afraid to contact me directly if you need help setting it up). I'm very much not a character artist so I'd love to hear back from folks, and see how this shader works in a wide variety of aesthetic/stylistic treatments!
     
  43. KRGraphics

    KRGraphics

    Joined:
    Jan 5, 2010
    Posts:
    4,458
    I'll be very glad to take you up on that offer. I am still translating my character models to Alloy.
     
  44. dixitalgorismi

    dixitalgorismi

    Joined:
    Aug 6, 2013
    Posts:
    30
    Hi Xenius, I'm using the SSE engine for SD4 to generate the materials. I thought that the Iris pro might be the reason for the problems. But since all but the most expensive Macbook Pro Notebook from late 2013 have integrated graphic chipsets, this might be something you/allegorithmic should address. The performance of these new chipsets are btw not comparable to the earlier models. Can't say anything about how well the OGL drivers are implemented for them. But no performance/rendering problems at all so far with my other pipeline tools like Modo and Unity. Even Mudbox works!

    Thanks for asking Xenius :)
     
  45. xenius

    xenius

    Joined:
    Sep 30, 2010
    Posts:
    523
    @Everyone Hi Guys!

    I know a number of folk have been asking about whether Alloy works well on other platforms. Well we've been listening, and we're excited to announce our first new platform, many of you might have heard of it, the Commodore 64!

    $Alloy_C641.jpg

    We've been following the C64 platform for a while now, and think its going to be the next hot marketplace for the Unity Community, so we decided to jump the gun, and even though official Unity support for the C64 build target doesn't exist yet, we've ported Alloy, and some of our demo content over to the platform!

    $Alloy_C642.jpg

    We here at RUST know that performance is always a concern, especially with PBR. It was a struggle, but we've managed an amazing 4-5 fps at an astounding 320x200 pixel resolution! That's including several image effects, HDR and Linear mode(running in indexed color), and our always-popular Marmoset Skyshop Support! If you'd like to check out how incredible Alloy looks on C64, come check out our C64 Materials Demo!

    http://alloy.rustltd.com/C64/
     
  46. KRGraphics

    KRGraphics

    Joined:
    Jan 5, 2010
    Posts:
    4,458
    Not bad for a commodore. :p
     
  47. lod3

    lod3

    Joined:
    Mar 21, 2012
    Posts:
    671
    *checks the date*
     
  48. FogGobbler

    FogGobbler

    Joined:
    Mar 25, 2009
    Posts:
    147
    LOL :) Stupid me sold my Commodore 64 and now it´s the next gen console :-( .
     
  49. dixitalgorismi

    dixitalgorismi

    Joined:
    Aug 6, 2013
    Posts:
    30
    I don't seem to have much luck with Alloy. The situation: I create a new project with a single empty scene. Add a cube there. Import Alloy from the asset store, install the shader pack inside. Set light to linear, cam to HDR. I create a new material and set the shader to Alloy/Core/Base Bumped.

    When I build for OSX (32 bit), i get the following output:

    Code (csharp):
    1. Unloading 4 unused Assets to reduce memory usage. Loaded Objects now: 1843.
    2. Total: 7.617326 ms (FindLiveObjects: 0.109346 ms CreateObjectMapping: 0.010919 ms MarkObjects: 5.661398 ms  DeleteObjects: 1.010009 ms)
    3.  
    4. System memory in use before: 138.0 MB.
    5. Unloading 0 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
    6. System memory in use after: 138.0 MB.
    7.  
    8. Unloading 0 unused Assets to reduce memory usage. Loaded Objects now: 1848.
    9. Total: 8.169141 ms (FindLiveObjects: 0.134096 ms CreateObjectMapping: 0.018052 ms MarkObjects: 7.954824 ms  DeleteObjects: 0.010231 ms)
    10.  
    11. Unsupported: Alloy/Nature/Terrain/Bumped
    12. Unsupported: Hidden/Alloy/Nature/Terrain/Bumped AddPass
    13. System memory in use before: 1.67 GB.
    14. Unloading 79 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
    15. System memory in use after: 410.8 MB.
    16.  
    17. Unloading 164 unused Assets to reduce memory usage. Loaded Objects now: 1779.
    18. Total: 699.609192 ms (FindLiveObjects: 0.114903 ms CreateObjectMapping: 0.050667 ms MarkObjects: 19.452761 ms  DeleteObjects: 659.637634 ms)
    19.  
    20. System memory in use before: 168.6 MB.
    21. Unloading 4 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
    22. System memory in use after: 149.7 MB.
    23.  
    24. Unloading 3 unused Assets to reduce memory usage. Loaded Objects now: 1827.
    25. Total: 9.212246 ms (FindLiveObjects: 0.138487 ms CreateObjectMapping: 0.010363 ms MarkObjects: 5.509253 ms  DeleteObjects: 2.883441 ms)
    26.  
    27.  
    28. Textures      784.2 kb   18.9%
    29. Meshes        0.0 kb     0.0%
    30. Animations    0.0 kb     0.0%
    31. Sounds        0.0 kb     0.0%
    32. Shaders       908.7 kb   21.9%
    33. Other Assets  0.5 kb     0.0%
    34. Levels        9.2 kb     0.2%
    35. Scripts       0.0 kb     0.0%
    36. Included DLLs 2.4 mb     58.7%
    37. File headers  12.1 kb    0.3%
    38. Complete size 4.1 mb     100.0%
    39.  
    40. Used Assets, sorted by uncompressed size:
    41.  768.1 kb    18.5% Assets/Alloy/Shaders/Resources/DiffuseScatteringOnRing.png
    42.  704.8 kb    17.0% Assets/Alloy/Shaders/Core/Base Bumped.shader
    43.  155.2 kb    3.7% Assets/Alloy/Shaders/Resources/Internal-PrePassLighting.shader
    44.  43.6 kb     1.1% Built-in Shader: Bumped Diffuse
    45.  16.1 kb     0.4% Assets/Alloy/Shaders/Resources/Default_AlloyRS.png
    46.  2.8 kb  0.1% Assets/Alloy/Editor/Resources/AlloyVisualize.shader
    47.  1.4 kb  0.0% Assets/Alloy/ImageProcessors/Editor/Resources/AlloyNormalBlit.shader
    48.  0.9 kb  0.0% Assets/Alloy/ImageProcessors/Editor/Resources/AlloyPassthroughBlit.shader
    49.  0.4 kb  0.0% Assets/foo.mat
    50. System memory in use before: 148.2 MB.
    51. Unloading 1 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
    52. System memory in use after: 145.9 MB.
    The lines 8-15 are of interest to me. The build packer seems to take 1.67 GB for this simple scene. Why I'm writing you this? Because for my real project and scene, the build exits with a out of memory error. 1.67 GB seems a bit harsh on the memory side for a (32 bit application) build process. I'm building on a Macbook Pro with a Iris Pro with 1024 MB men. So this leaves around 1.300 MB to the 4 GB memory allocation border. In this case enough, but not for a non-trivial real scene.

    P.S.: I also tried to build for 64 bit OSX, but the result is same. This is expected though as the build process is 32 bit, even when building for 64 bit.

    EDIT: I just also tried your demo scene from the package and it works. Sorry for sending you in the wrong direction. I'm still puzzled why my scene breaks building when I use Alloy shaders... The same scene with standard diffuse works fine.
     
    Last edited: Apr 2, 2014
  50. Deleted User

    Deleted User

    Guest

    Hi xenius,

    I'm really need your support urgently. I am trying to make Allegorithmic's Bitmap2Material (B2M) work with Alloy, more precisely with your Material Map Channel Packer (MMCP).
    Since you guys are working closely with Allegorithmic I thought you might be able to provice a quick fix.


    Here is the issue:


    As you might know B2M automatically creates Spec, Normal, Height, AO Maps etc. based on a diffuse input texture. Very similar to what CrazyBump does, but B2M does it inside of Unity. As you can see in the attached screenshot these maps are somehow encapsulated inside a B2M material. Despite them being encapsulated, I can drag and drop these maps just fine to any material slots (e.g. of the Unity standard shaders or Skyshop shaders). However, I can't seem to drag and drop them onto the MMCP. The "Select" dialogue of the MMCP isn't able to see those encapsulated maps, so drag and drop is probably the only way to go.


    This is a major issue for me as I need this feature urgently :( I want to create maps with B2M, tweak them with instant feedback in the viewport, and then have the MMCP automatically pick up these changes and update the packed map accordingly.

    Can you figure out why the MMCP doesn't allow me to drag and drop the B2M output maps? I would be endlessly grateful if you could add this functionality to Alloy soon in case I'm not just missing something here. I think a lot of people use B2M and the more people are going to use Alloy, the more this functionality could be asked for anyway I think.


    Thanks a lot!


    Sean
     

    Attached Files:

    • $B2M.jpg
      $B2M.jpg
      File size:
      198.4 KB
      Views:
      977
Thread Status:
Not open for further replies.