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 - Alex Jenyon

Pages: [1] 2 3 ... 8
That’s a fundamental limitation of displacement maps, unfortunately.  The rapid falloff in height at the hard edges on each grass blade is covered by only one or two polygons, so the ‘stretched’ look is always going to be an issue.

There are a couple of things that might help, but none will be a perfect solution:

- Make the height falloff at the blade edges not as sharp, by rounding, blurring or bevelling.  Not as crisp-looking or realistic, but will avoid as much ugly polygon shearing.

- Reduce the overall height of your displacement.  Not ideal, but displaced grass won’t work super close-up anyway, so you might get away with it, and this would reduce the problem, too.  Obvious, but worth considering!

- Try to create your grass blades using vector displacement.  Not at all easy to author in substance designer, but it’s been done.  This will allow actual overhangs, but is often really tricky to set up in the target renderer as well.

- Add an opacity map, and create your grass in a couple of layers.  Obviously heavier, but most of your existing work would be directly re-usable.

- Abandon tesselation entirely, and create a tiling mesh from overlapping strip curves.  Throws away a lot of your work, which would be frustrating, but should enable you to maintain the same look.  Might actually be lighter, too.

- Abandon tiling, and go with a mesh scatter solution.  Throws away basically all your existing work, but I figured it was worth adding for completeness.

Without knowing what renderer you have in mind, it’s difficult to answer.

Most shaders have some function that would allow you to add two user variables and a switch, and adjust the tiling depending on the output from the .sbsar

Substance graphs, even really complex ones, can’t produce more than a texture set with specific pixel dimensions - some internal nodes have the concept of physical scale, but this information isn’t normally included in the output.

It is theoretically possible to add it as metadata to the .sbsar, (described here) but it looks to be a pretty horrible process. 

A flood fill ‘random colour’ node is effectively 3 ‘random greyscale’ nodes stacked together.  It doesn’t quite get you the five masks you’re after, but it can save a bit of annoying duplication - just separate out the channels once it’s generated.

I’ve solved a similar problem by deleting the application preferences.  Was this one of the things you tried?

I’ve come across a similar issue in the past with very heavy (4M+ meshes).

In my case, the baker was using the GPU, so it seemed to be a graphics card (I suspect VRAM) issue rather than a regular RAM one.

The fact that it’s crashing on the most intensive bakes, rather than the first one, suggests the mesh is loading just fine, and you might have a similar problem.  It caused the display driver to crash entirely - so there was never time for substance to generate a crash report.

Possible to are seeing something similar?  In my case, upgrading to a 1080ti solved my issue, at least until the meshes got even heavier.

You could convert the normal map into a height field, and then use a triplanar node to map your texture onto it.

You could also split the split out the R + G channels of the normal map, and warp your texture using the R channel, and then the G channel. 

This second approach would only distort the input texture in 2 directions (I.e. up and right, not up + down + left + right).  For a more sophisticated approach, you could split each channel in half again, mapping values 0-128 into one warp node, and values 128-256 in another with the angle set to opposite direction.

Hope these outlines make sense - can put together some visual examples if they don’t.

Substance DesignerSubstance Designer - Discussions - Re: map deepness
 on: December 26, 2018, 06:57:53 am 
I assume you’ve tried the intensity setting of the ‘normal’ node, and it wasn’t enough?

The normal map illusion only really works if there are graduated transitions in the height map - if the source map has edges that are too sharp (black to white in only a few pixels), it’s not as convincing.

Adding a ‘bevel’, ‘distance’ or even just a ‘blur’ node in front of the normal conversion might help to smooth out the height map, and give the normal node something to work with.

If I follow the image link directly, I get a ‘403 forbidden’ error.

Likely, you need to be logged in to the site to see the images, so it won’t show up here.

Use a common host, like imgur, photobucket, google photos, or something similar.

That’s actually a really interesting question - and a pretty cool workflow (if it could be done).

It may be possible to use a pixelProcessor node to find out the positions of the white corner pixels, and use these values to calculate the scale and offset in a transform node.

Not sure I’ll have time outside of work for a little while - but I’ll give it a go at some point.

I would do it in the tile sampler itself:

The only funky part is that the Tile Sampler Colour and the Tile Sampler Greyscale behave slightly differently when handling the alpha blending of the top and bottom rows of tiles. 

Generating the colour sampler with 2 x the resolution and 2 x the tile count, and then scaling it by 200% solved this problem.  There may be a more elegant way of doing this - it's a bit 'brute force', but it is a pixel perfect match.

Patterns that are irregular, but have underlying structure, are a bit of a limitation with substance right now.

There's no current method of creating 'packing' logic, but it's come up enough times that hopefully the tools will be added in future.

This is the closest I can get - starting off with the same cells pattern, and then using some anisotrophic blurs to 'square' some of the irregular shapes.  It's missing the sharp corners, and has some large gaps:

Yes, they are.

It’s one of the reasons there’s two formats (.sbs and .sbsar), and why .sbsar files can be considerably larger than the .sbs that created them.

Try the following:

Separate out the green channel from your position bake (using an RGBA split node).  I’ll call this G.

Feed the curvature into a ‘slope blur’ node, using G as the ‘slope’.

Create another ‘slope blur’ node, and feed in the curvature again, but this time use the inverse of G as the slope (feed it into a ‘invert greyscale’ node first).

Combine the two outputs.


You might then try overlaying the result on top of itself (maybe in combination with a levels node) to strengthen the areas of stronger curvature, and reduce the weaker ones.


This would be amazing.

It's possible to do this (sort of) using substance batch tools - but it's clunky, obtuse, and confusing.  This suggestion would make layered material workflows much more elegant.

I spent a large part of my day at work yesterday figuring this out.  There doesn't appear to be any documentation, and a bunch of it is hidden in a gif in another forum post.

For people struggling with the same thing, here's a really basic run through:

1.  If you've baked UDIMs, presumably you imported a mesh with UDIMs correctly.  Obj seemed to work for me, fbx did not - at least with my meshes yesterday.

2.  As the post above states, you need to right click on the material (the line underneath your mesh), and choose 'assign substance to all UV tiles'. 

3.  A 'clone' of your chosen graph will appear in a new line.  Double click to load the clone.
NOTE:  You can edit either the original OR the clone, but only the clone will show UDIM tiles.

4.  You will see a drop down menu appear in the far right of the top toolbar, allowing you to select a UDIM tile
NOTE: I didn't see it at first, because the toolbar wasn't wide enough.  Make sure it's not hidden!

5. If you choose 'export outputs', you'll see the 'from graph' option selected by default.  Even if you add the $(udim) variable, it won't export all your tiles

6.  Choose 'batch' mode instead, and you'll see a list of UV tiles to export.  This tab doesn't remember the 'Destination' path from the 'from graph' tab, so you might need to check this. 

Hope the images help


Pages: [1] 2 3 ... 8