Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - NevTD

Pages: 1 [2] 3 4 ... 9
16
It outputs to current directory if no output path is provided.

Are you using a 4k or other high dpi monitor by chance?
My guess is that's what's triggering your QT_DEVICE_PIXEL_RATIO warning.
Either way it's safe to ignore on your end.

17
Just jumping in here as I've encountered the QT_DEVICE_PIXEL_RATIO warning before (unrelated to SAT) and it can often be innocuous (not saying it's the case here).

Out of curiousity, can you run your command with --verbose to see if any relevant details are provided regarding the output?
Code: [Select]
.\sbsbaker.exe ambient-occlusion "D:\Download\Bake Test\ORT3500A hus.fbx" --output-size 10,10 --verbose
Have you also tried baking with the --output-path command, in case it's a permissions issue?

18
This is good to hear, hopefully we can do some render testing on my end to determine if it's worth going RTX over a Radeon VII.

Thanks again for reporting your findings.

19
I appreciate you posting an update, as I've been curious about the results myself.

I know there's other factors that contributed towards the faster process time, but just to clarify; are you saying it took 40 min with 8GB and 5 min with the 16GB?

What was the other card that you used?

20
And just in case I misunderstood your requirements; if you're asking to force the resolution in the material directly rather than using the sbsrender --set-value flag.

Just replace:
Code: [Select]
    graph.setBaseParameterValue(
        aParameter=sbsenum.CompNodeParamEnum.OUTPUT_SIZE,
        aParamValue=[sbsenum.OutputSizeEnum.SIZE_1, sbsenum.OutputSizeEnum.SIZE_1],
        aRelativeTo=sbsenum.ParamInheritanceEnum.PARENT
    )

    # Hackey inheritance override.
    for param in graph.mBaseParameters:
        if param.mName == 'outputsize':
            param.mRelativeTo = str(sbsenum.ParamInheritanceEnum.PARENT)


With:
Code: [Select]
    graph.setBaseParameterValue(
        aParameter=sbsenum.CompNodeParamEnum.OUTPUT_SIZE,
        aParamValue=[sbsenum.OutputSizeEnum.SIZE_4096 , sbsenum.OutputSizeEnum.SIZE_4096],
        aRelativeTo=sbsenum.ParamInheritanceEnum.ABSOLUTE
    )

    # Hackey inheritance override.
    for param in graph.mBaseParameters:
        if param.mName == 'outputsize':
            param.mRelativeTo = str(sbsenum.ParamInheritanceEnum.ABSOLUTE)

The latter should ignore the --set-value '$outputsize...' flag and use the base parameter outputsize value instead.

21
Nevermind, I digged a bit into the source code; here's a hackey workaround to force the inheritance mode.
Try the script in my previous post first. If it doesn't change the outputsize inheritance mode, try the script below.

Note: As I mentioned before, this will overwrite the sbs file being processed; try it out with a test material and add your own backup mechanisms.
Code: [Select]
from pysbs import context, substance, sbsenum

sbs_mtls = [] # Your list of sbs files to process.

def set_sbs_graph_to_relative(sbs_path):
    # Build doc.
    ctx = context.Context()
    sbs_doc = substance.SBSDocument(ctx, sbs_path)
    sbs_doc.parseDoc()
   
    # Get your graph.
    graph = sbs_doc.getSBSGraphList()[0]
   
    # Change the outputsize inheritance value.
    # Bug: The aRelativeTo argument doesn't appear to do anything.
    #
    # https://docs.substance3d.com/sat/pysbs-python-api/api-content/libraries/sbsenum
    graph.setBaseParameterValue(
        aParameter=sbsenum.CompNodeParamEnum.OUTPUT_SIZE,
        aParamValue=[sbsenum.OutputSizeEnum.SIZE_1, sbsenum.OutputSizeEnum.SIZE_1],
        aRelativeTo=sbsenum.ParamInheritanceEnum.PARENT
    )
   
    # Hackey inheritance override.
    for param in graph.mBaseParameters:
        if param.mName == 'outputsize':
            param.mRelativeTo = str(sbsenum.ParamInheritanceEnum.PARENT)

    # Save pkg.
    sbs_doc.writeDoc()
   
for pkg in sbs_mtls:
    set_sbs_graph_to_relative(pkg)
   

22
I couldn't find a way to do this in sbsmutator; however, I was able to use pysbs to set the default parent inheritance value for outputsize, however, I can't find a way to switch the inheritance mode from absolute to parent.

I'm using a much older version of SAT, so it's possible it's a bug that's been resolved since.
Try it on your end and see if you can get any further with the script.

Note: This will overwrite the sbs file being processed, so use at your own risk. Preferably with an isolated test material.
Code: [Select]
from pysbs import context, substance, sbsenum

sbs_mtls = [] # Your list of sbs files to process.

def set_sbs_graph_to_relative(sbs_path):
    # Build doc.
    ctx = context.Context()
    sbs_doc = substance.SBSDocument(ctx, sbs_path)
    sbs_doc.parseDoc()
   
    # Get your graph.
    graph = sbs_doc.getSBSGraphList()[0]
   
    # Change the outputsize inheritance value.
    # Bug: The aRelativeTo argument doesn't appear to do anything.
    #
    # https://docs.substance3d.com/sat/pysbs-python-api/api-content/libraries/sbsenum
    graph.setBaseParameterValue(
        aParameter=sbsenum.CompNodeParamEnum.OUTPUT_SIZE,
        aParamValue=[sbsenum.OutputSizeEnum.SIZE_1, sbsenum.OutputSizeEnum.SIZE_1],
        aRelativeTo=sbsenum.ParamInheritanceEnum.PARENT
    )
   
    # Save pkg.
    sbs_doc.writeDoc()
   
for pkg in sbs_mtls:
    set_sbs_graph_to_relative(pkg)
   

23
Code: [Select]
sbsrender render --output-path '{inputPath}' --set-value '$outputsize@4,4' --output-format 'tif' --inputs /file/location/xxx.sbsar
What you have there with --setvalue '$outputsize@4, 4' is the correct way of doing it (except 4k would be --setvalue '$outputsize@12, 12').

As you suspected, the issue is the resolution defined in the materials, so you'll have to fix them.
This might help: https://docs.substance3d.com/sat/setup-and-getting-started/frequently-asked-questions

24
I've been dealing with this myself for the past couple of years now so I'll try to provide some insight.

Quote
I will be developing a SAT pipeline for our studio and I am trying to figure out what would be the best approach.
VFX/animation or gaming? Your approach varies based on this (single vs multiple UDIMs).

Quote
From what I read, SAT baker is not able to cache 3d geometry between tasks which could make baking pretty time consuming, so I am thinking about the option of doing the baking in Designer and continuing with SAT from there..
You're absolutely correct. I've done intensive testing with this and it will only be a noticeable problem for you if you're dealing with high poly geo (> 5 million) with lots of UDIMs (> 20).

My highest quality test case was 5m poly's (1773 objects) with 7 bakers and 78 UDIMs (546 tasks). The overhead between each task was ~6 seconds, which ended up adding an extra hour to the baking process on a single machine (compared to Designer/Painter).

That being said, the advantage you'll have with SAT is that you can break down your sub-processes per UDIM/task and propagate them to your render farm. Since they'll run in parallel, it will outperform a geo cached bake on a single machine.

If you're dealing with a gaming quality, single UDIM asset, you likely won't lose more than a few seconds between each task by going the SAT route.

Quote
I would also like to decide what is the better solution for material assignment - having a huge graph with all possible materials from our library and feeding just the color ID map to blend between them, OR picking just the IDs for the current geometry and build the specific graph for each geo procedurally from there.
Can't offer much advice here on the best approach.
I've opted for a material library where all our Substance materials get published. Material propagation is handled per UDIM, via in-house tool that interacts with the library.
If I had to guess; a single sbs acting as a "library" of sorts, would likely increase overhead time significantly, as each graph would have to be loaded.

Quote
And one more thing, not sure if it's a real issue or just the outdated documentation, but SD API is said to be compatible with python 3.6, while SAT works with python 2.7/3.5
I'm currently running project callbacks in Designer which makes calls to SAT command line tools.
You may run into compatibility problems with pysbs, but the command line tools should work just fine.



25
SAT includes a bunch of command line tools and a python wrapper for them (Pysbs).

You can absolutely create a custom SD plugin that uses both, the SD API and launches SAT sub-processes with the relevant data.
To an extent, SD is already doing this (it uses both sbsrender and sbscooker), so nothing is preventing you from extending that functionality further.

I can try to provide more feedback if you provide a use case.

26
There doesn't appear to be a higher level function to retrieve the group from the property, but there's still a way.

Example for your current graph:
Code: [Select]
for prp in graph.getProperties(sdproperty.SDPropertyCategory.Input):
    group = graph.getPropertyAnnotationValueFromId(prp, 'group')  # Docs: sbs::compositing::input
    if group:
        print('{}: {}'.format(prp.getId(), group.get()))

Example for a node:
Code: [Select]
graph = node.getReferencedResource()
for prp in graph.getProperties(sdproperty.SDPropertyCategory.Input):
    group = graph.getPropertyAnnotationValueFromId(prp, 'group')  # Docs: sbs::compositing::input
    if group:
        print('{}: {}'.format(prp.getId(), group.get()))


Docs

sbs::compositing::input

../Allegorithmic/Substance Designer/resources/documentation/pythonapi/html/pythonapi/modules/sbs_compositing.html?highlight=group

27
I know SAT was included when I purchased an indie subscription in Nov 2018, is this not the case anymore?
Or are you referring to a perpetual license?

I agree about the lack of optics around SAT; I've mentioned this before as well since it was impossible to figure out which purchasing options included it.

There was a huge push promoting SAT when it was released a few years ago, but over time there's been so much secrecy and obscurity around the product; down to removing it completely from the website.
Most developers/studios I've worked with aren't even aware of its existence, despite using Substance for years.

I sometimes question if long term support is even planned for it.

28
If I understand your question correctly, you're looking for the 'defaultParentSize' value (Parent toolbar).

This value is stored as an 'option' of the graph, which doesn't appear to be currently supported by the SD API (at least not the version I'm using 2018.3.1).



I did look into the SAT pysbs API and it does appear to support options for the graph object (although I haven't tested it).
https://docs.substance3d.com/sat/pysbs-python-api/api-content/substance-definition/graph#graph.graph.SBSGraph.getOptions

Possible workaround (assuming you have access to it) until they implement it?

30
I noticed we can also set values into the sbsar referenced graph and these are taken as default values (i.e. when using "Reset to default" menu on instance parameters, these show up). I am not sure why this is enabled as this is rather "dangerous", we are not supposed to modify the defaults of an sbsar which should be read-only I guess.
When you're modifying the default value via node.getReferencedResource().setPropertyValue(), correct?

Interesting, I just looked into this and it does appear to be changing the default values.

However, it does not save these changes to the source package unless you explicitly tell it to. Or in the case of sbsar's, I'm not even sure if you can.

What it appears to be doing instead is creating a cached version of that package that gets used for the duration of your Designer session.
If you re-launch your Designer session, the properties will go back to the default values that were in the package file itself.

I'm not sure what the point is in allowing the user to do this.
I agree this is unpredictable behavior, can be potentially dangerous and should probably not be implemented the way it currently is.
Ideally it should be a read only SDCompGraph representation with all the set methods stripped out.

Pages: 1 [2] 3 4 ... 9