0
$\begingroup$

I'm continuing to work on a procedural skin system, and it's got so complex that my PC is having trouble running it. My workaround so far has been to just turn parts of it off while I work on other parts, but eventually I have to turn them all on to see the results anyway, so I end up with the same problem.

So I've decided it's time to try simplifying the actual math. My idea was to use the Truncate node, but the way it's coded I lose all the fine data. That's because Truncate limits to Integer values, but my fine details are all calculated in the decimal spaces. The reason these values are bogging down my PC are they go down into many many decimal places.

I tried making a node group which multiplied the values, fed that into a Truncate node, then divided that result to get the decimal points truncated, but it didn't work.

So what I need is a way to make a Truncate node with the ability to choose the decimal place that it truncates to.

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ "The reason these values are bogging down my PC are they go down into many many decimal places." Are you sure about that? I'd almost swear floatpoints operations always take the same fixed amount of digits into account, whether they are significant or not. $\endgroup$
    – Duarte Farrajota Ramos ♦
    Mar 21 at 19:51

1 Answer 1

Reset to default
2
$\begingroup$

I am afraid the answer is: this is pointless.

You will still have 32bit floats, but way more calculations. Binary numbers have little to do with how many digits decimal numbers have as far as I know. They are also stored in a specific floating point format. So this is no way to speed things up. You should choose another path. Try making the shader less complex and more efficient. Don't process data that you don't need. For example, don't use color that is composed of 3 channels if you need only one, don't use 3d procedural textures when you can use 2D, try to replace complex nodes with simpler ones like for example people tend to overuse Color Ramp, when they can often get away with Map Range and so on, some other nodes can be replaced with math as well. Do tests though, to find out what is more efficient.

Improve this answer
$\endgroup$
11
  • $\begingroup$ Also just show us the nodes in question if you want advice on how to make them faster. $\endgroup$
    – Martynas Žiemys
    Mar 21 at 19:57
  • $\begingroup$ At this point if I tried to do that, I would have to flood this page with screenies, cause there's no way I could show them in one. On the subject of 32-bit floats, at what decimal point is it cutting them off, because I have some values being divided multiple times before being combined and then fed into the shader groups. $\endgroup$
    – MisterLBlends
    Mar 21 at 20:05
  • $\begingroup$ It doesn't change the fact that what you are trying to do here has absolutely no chance to help you achieve desired result. You need to look for another solution in any case. Maybe ask a new question about your specific nodes and share the .blend file if possible. Or maybe look for other ways to achieve what your shader does. $\endgroup$
    – Martynas Žiemys
    Mar 21 at 20:11
  • $\begingroup$ "at what decimal point is it cutting them off" - at none. They are not decimal, they are binary when calculations happen. The precision is limited by storing binary values and converting between decimal and binary. $\endgroup$
    – Martynas Žiemys
    Mar 21 at 20:14
  • $\begingroup$ Well that sucks. I guess I'll just have to keep trying to save for a new workstation. I've already optimized this system as much as I can by being choosey about my nodes and having my colorramps doing as much double-duty as possible already. My goal is photorealism so there's only so many corners you can cut. $\endgroup$
    – MisterLBlends
    Mar 21 at 20:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .