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.

Topics - Thibaud Van Vreckem

Pages: [1]

We are using ue4 to develop a pre-production previz studio tool.
the product visualised are embossed product with very fine detail and resolution.
We noticed some artifacts (squares appearing at the edges of the relief) in the final 3d renderings.
Cfr attached 500% crops of the artefacts (normal red channel) compared to the substance designer output.
It turns out the artifacts comes from the generated normal map, and are due to the map compression scheme, which (and that's the culprit here) can't be changed in the UE4 plug-in integration.

This is a serious showstopper and after more than 6 months of development on this project we are now considering switching to unity in which substance apparently doesn't have any of theses limitations.

I'd love to hear any potential options I could explore to solve this issue. (Using externally generated map isn't an option. as the core principle of the tool we are building is the procedural generation based on inputs)

Thansk a lot.

The project I work on requires a 8192 x 8192 resolution. (Designer & Player both support it)
Although UE4 engine allows 8192 x 8192 textures. I just found out that unreal plugin is limited to 4096x4096 (either CPU or GPU version).

Is there a table somewhere showing the output resolution limit of all substance integrations ?
what would be my options to lift that limitation in UE4 ?

For some reason the substance integration does not allow to select resolution (labeled as width & height) beyond 4096 x 4096

For some reason the grouping hierarchy of the published substance is completely ignored in Tootlbag 3.08
everything is placed under a 'Settings' sub group of the Substance

A drop down list parameter in a substance that start with a 0 index when published and imported in marmoset will display all entries correctly but will internally shift the selection so there is no way of actually using the first entry.

0 | Label 1   < Selected
1 | Label 2   < Actually using
2 | Label 3

Drop down list that start with index 1 don't seem to have the same problem.

1 | Label 1   < Selected & actually using
2 | Label 2
3 | Label 3

I'm using the amazing tile sampler in my graph and would like to expose it's pattern drop down selection to the graph.
but with a reduced patterns list.
So I've added as input tweak in my graph a integer1 parameter of type dropdown list.

and I wired the Tile sampler pattern dropdown to that graph parameter.

The problem is that for some reason changing the parameter does not update or change the tile sampler output in any way.
Is there any restriction related to way the tile  Sampler is constructed or did I miss something else ?

Ok the problem actually occurs when changing the dropdown selection in the preview tab.
Things seems to work ok when changing the default checkbox in the parameter tab

On this doc page:
the following sentence:
"Lets you use another value than black as default input, if nothing is connected to this slot. Since SD 2020.2"
hints at a functionality present in 2020.2.
are the doc ahead of the release schedule ? because I don't think 2020.2 is a thing yet.

Pages: [1]