Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Oct 02 9:25 am)
P.S. This is the first, very basic, step in trying to do something clever (dangerous, I know!) to pseudo-randomize the order...
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Found it !
If I simply swap the inputs to the subtract node so I'm calculating ( V - (V mod 0.03125) ) instead of ( (V mod 0.03125) - V )...
But I don't understand why.
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Now to find a simple* formula that will convert any integer** in the range 0-31 to a (probably, but not necessarily) different integer in the same range. Without any number being duplicated. That can easily be done in Poser's Material Room.
*Unfortunately the standard simple pseudo-random number generators that I know of use the result of the first calculation as the input to the second, and thus aren't really suitable. Maybe some sort of look-up table ? But how would I implement that ?
**Yes, I'm considering 0 to be an integer here
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Because the 'Image_Mapped' is set to 'Tile' I'm wondering if something as simple as J = (N × I) might work, where I is the original integer, J is the new integer, and N is an appropriate multipler (definitely something that isn't a factor of 32, and probably a prime number? )
I did a bit of paper and pencil scribblings using N=5 and that seems to work (figures in brackets should be the modulo 32 values)...
0, 5, 10, 15, 20,25, 30, 35 (3), 40 (8),... 60 (28), 65 (1) ... 95 (31), 100 (4), ... 125 (29), 130 (2), ... 155 (27)
Does anybody know for sure* or do I need to do a spreadsheet to work it out ?
*this probably involves a link to a mathematical proofor something like that
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
If the above is true, then I just need to convert the variable v (0.0-1.0) to my set of integers 0-31 based on the non-remainder part of a modulo 0.03125 calculation (or an integer division; or V%0.03125 as I vaguely recall from some maths; or whateverit's properly called - I think I remember 'modulus' and 'remainder' ?)
v = 0.0 to just below 0.03125, I = 0
v = 0.03125 to just below 0.0625, I = 1
...etc...
In Poser's Material Room of course. I don't think it's too hard, and I'm fairly sure that I've done it before. Several times. But my brain's getting rustier...
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
From the lore of Bagginsbill, the U and V inputs for most nodes, supply U and V when nothing is plugged into them. The values plugged in are subtracted from the inherent value, so plugging a constant 1 into V, gives V - 1. Plugging V into V, gives V - V, or a constant 0. So, (internal V) - (plugged in V - (V mod 0.03125)) gives +V mod 0.03125 which is a sawtooth with 32 teeth along the V axis.
Floor( 32 * V) will give 0..31 over the range 0..1, with 32 right at the last pixel where V = 1. So you could replace 32 with 31.999999 to ensure you never get 32. (Provided the internal float representation is not exactly the same as float(32))
Several folks, including myself, have done various scripts for taking an input value and turning it into a colour code or a string of digits. That kind of modulus and remainder chain function would be a good way to generate a sequence of values from an input number (seed). Randomisation is hard without recourse to much calculation.
However, doing something pseudo-random might be possible with a bit of pre-calculation.
Using the python commands in Poser's python shell:
>>> import random
>>> random.sample(xrange(32),32)
[2, 22, 1, 25, 23, 8, 15, 19, 21, 30, 5, 3, 29, 9, 6, 27, 28, 14, 13, 17, 10, 0, 24, 16, 7, 18, 11, 12, 4, 26, 31, 20]
gives a randomly ordered list you could package up into values that can be represented by feeding the various integers into inputs of ColorRamp nodes set to white, which chain together to divide up your input value into one of 32 different input ranges between 0 & 1. To introduce further randomisation, you could multiply your V input by one of the P node position coordinates and reapply the modulus, meaning if you move the object, the output values will be offset from their previous values.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
Here's the Working Digital Clock and the SM Poser Forum thread where it was discussed Works-in-progress, in case the description is useful to understanding the shader.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
Thanks:
'Floor' was what I was after (why didn't they just call it 'RoundDown' ?)
I really want to try and avoid scripts for this. I want to do it in the material
And luckily "sort-of-randomish-looking" is good enough
I just did a quick spreadsheet which proved to my satisfaction that J = (N × I) provides satisfactory results for any odd value of N (1, 3, 5, 7, etc). Once you get above 31the results repeat, so J = (35 × I) returns the same sequence as J = (3 × I), etc.
Ignoring N=1 (which gives the original sequence) and N=31 (which gives the original sequence in reverse) that gives me 14 sort-of-randomish-looking sequences.
Which I think is probably sort-of-good-enough-ish for my purposes
P.S. I noticed that a fewposts down from that Works-in-progress that you linked to bagginsbill posted a link to my Ten Digit Visualizer at ShareCG. I'm chuffed : !
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Given that you have 2.63e35 odd possible permutations of 32 books (many of which will not look random when seen numerically), I shouldn't imagine you'll bother with an exhaustive list of possible sort orders ?But, of course given that your original texture looks like a random sort (i.e. no rainbow sequence of colours), whether the indices appear random is irrelevant.
I certainly wasn't suggesting a script in this case, just that the output of a script is easily accessible to feed you a starting random order, which it will be simple to modify with nodes to get other orders, as you're doing.
Yes, affirmative mentions by the node master are quite the temptation for brachycephaly (head swelling)
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
an0malaus posted at 9:15PM Mon, 12 August 2019 - #4359194
...Yes, affirmative mentions by the node master are quite the temptation for brachycephaly (head swelling)
Brachycephalic is a great word, although I prefer dolichocephalic...
(I learnt both many, many years ago when I was reading Henri Hubert's "The Greatness And Decline Of The Celts", and I swore that I'd use them in everyday conversation...
...I failed)
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Ah, dolichocephalic, as in Nefertiti and the Mayan/Incan (and I see also certain Pacific Islanders') practice of head binding in infants to produce elongated skulls. I had not previously come across that word, though I was familiar with the practice, having spent decades bashing my forehead against code/management walls. ?
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
Don't forget the aliens...their cephalics are extraordinarily dolicho !
(I do so love talking rubbish )
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Back to the pseudo-randomizing-ish thingy - adding an offset (so it doesn't always start with the same book) and using bagginsbill's parmatic (with a bit of manual setting for the min/max/sensitivity to restrict the dials to the allowed values) seems fairly "sort-of-randomish-looking" to me.
(For anybody who doesn't use parmatic they'd have to manually set the 'Value_1's of the two 'PM:'nodes in the material room. Not quite so delightfuly user-friendly, but perhaps good enough I think. Or maybe I could use a script after all - one that automatically runs from a "Randomize" icon in the 'Pose' folder)
And then of course, how about mixing books between the left and right columns of the texture map ?
And why stick to just one texture map ?
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Hey cool stuff. I have a node pattern to show you that allows the selection of real noise from the built-in noise nodes, but making it keep a constant value within different regions. So, for example, you can have tiles where each tile produces a different but random color, but all the same color within that tile. Or brick. Or hexagon, or circle. Any region you can describe with math.
Basically you manipulate the offsets of any noisy node (FractalSum, fBm, etc.) so that the coordinate is a constant for whatever region you want. The resulting patterns are unpredictable in color but completely controlled in shape. You then use the controlled-random colors to feed as offsets into your color image map.
E.g. if you calculate such that the internal X value for your chosen noise node is Floor(U * 7.99999) you will get a "fixed" set of 8 different X values from 0 to 7 that feed into your noise node. If you do the same in the Y dimension, and hold Z constant, the node becomes a 2D rectangular noise generator.
Will demo when I have more time but you may be able to figure that out on your own.
Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)
Thanks bagginsbill, that would be great. I'll also see if I can work it out for myself based on what you've said.
P.S. I tried to do something similar a couple of years ago. The best I could do was turning an image map into square tiles - Mosaic MT5 For Poser. I also tried creating 'unpredictable in colour' areas, but I resorted to the Cellular node, mode 5, RandomColor, as in this post on my books thread in the SM Poser forum. However, that didn't actually seem to work in the way I thought it did when I wrote that post (or the way the Cellular node works changed)
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Hang on a mo', and a quick rewind...
an0malaus posted at 10:06PM Fri, 16 August 2019 - #4359182
From the lore of Bagginsbill, the U and V inputs for most nodes, supply U and V when nothing is plugged into them. The values plugged in are subtracted from the inherent value, so plugging a constant 1 into V, gives V - 1. Plugging V into V, gives V - V, or a constant 0. So, (internal V) - (plugged in V - (V mod 0.03125)) gives +V mod 0.03125 which is a sawtooth with 32 teeth along the V axis.
That last sentence would explain why I needed to plug (V - Vmod0.03125) intoV_Offset,and NOT (Vmod0.03125 - V).
However, what came before that doesn't match what I actually see...
To start with, I'm assuming that "...the U and V inputs for most nodes..." includes the V_Offset for Image_Map nodes,yes ?
"...supply U and V when nothing is plugged into them." - hang on ! I thought it was a constant in that situation, i.e. the numerical V_Offset value in the Image_Map node. Regardless of vertical location on the image map.
"...The values plugged in are subtracted from the inherent value, so plugging a constant 1 into V, gives V - 1..." - what ? If I plug a Math_Function (Add, Value_1=1,Value_2=0) into an Image_Map V_Offset (value set at 1) then I get a constant offset 1. Again, regardless of vertical location on the image map.
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
The image x coordinate is U / U_Scale - U_Offset. The image y coordinate is V / V_Scale - V_Offset.
When you set U_Scale = 1 and U_Offset to 0 this simplifies to x = U. Similarly y simplifies to y = V.
"hang on ! I thought it was a constant in that situation"
What "it" are you asking about here, the image coordinate or the offset parameter?
The offset can be constant, but the coordinate (x, y) is not - it varies with U and V, because the expression defining the coordinate (x, y) is more than just the offset, it is (U / U_Scale - U_Offset, V / V_Scale - V_Offset). The coordinate is not the offset, unless you do something special.
When you set V_Offset to a constant, C, the image is shifted uniformly by y = V - C. The coordinates still change as you move about the surface. Visually in preview the scaled image appears to move up.
When you set V_Offset to an expression of the form V - p, the image coordinate is
y = V - (V - p)
{ get rid of parentheses } y = V - V + p
{ V - V is 0 } y = 0 + p
{ 0 + p is p } y = p
Magic. Letting p be any value you want the y coordinate to be, directly under your control, you connect V - p into V_Offset and set V_Scale = 1. A similar argument goes for x.
If you decide that p = C (a constant), and wire up the offset as (V - C) then the coordinate becomes
y = V - (V - C)
y = V - V + C
y = 0 + C
y = C
And NOW you have a constant coordinate. If you draw this, the entire surface will be colored ONLY by the color at that C coordinate.
Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)
Summary:
To force the image x coordinate to be P and the image y coordinate to be Q, you hook up nodes to the offsets as
U_Offset = U - P
V_Offset = V - Q
And now you have total control over the coordinate, independent of the U and V values. You are now free to do anything you want with the coordinates to look up whatever color you want at (P, Q)
Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)
An amusement with U_Offset = U - ((U - .5) / Bias(V, .7) + .5)
Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)
Thanks again - Sorry about that, I think my brain short-circuited !
I'll need to read through the susequent posts a couple of times when I'm a bit less drowsy.
But just so I don't lose it, I found this post on JoEtzold's 2008 "Bagginsbill or other guru - shader question" thread where you explained how to freeze/fix the scale inputs to certain 3D nodes. Here's what it said:
bagginsbill posted at 9:44PM Sat, 17 August 2019 - #3349465
You may be curious about what's going on with the Fractal_Sum node. This has nothing to do with this clothing item. I just needed some interesting curve to demonstrat bending the strip, so I used this node to make a curve. For the real thing, we'd need a specific curve, not a random one.
Anyway, I exploited here an interesting undocumented feature of the Fractal_Sum node. (A few others do this same thing.)
The FS node creates a 3-dimensional pattern that is superimposed on your model. This pattern, based on random numbers arranged with varying frequency, is normally sampled by the shader for each point of your geometry. Whatever value actually exists at that point in the 3d noise function is used by the shader.
Normally all you can do to alter the geometric layout of the pattern is mess with the scale parameters. The coordinates of your object are transformed using these scales to look up a value in the 3d noise. The coordinates come from your model, not the final transformed world coordinates.
But! I found that if you plug any node into those scale parameters - any node at all - they no longer use the model coordinates. Instead, they strictly use the value that is plugged in!
So what I did here was to plug in a math node into the Y_Scale and Z_Scale. This effectively freezes those axes. The pattern then transforms from being 3-dimensional to 1-dimensional. If you were to plug a math node into only one of those 3 parameters, then you would get a 2-dimensional pattern.
Now the remaining parameter, the X_Scale, I plugged in the V coordinate from my UV map. Thus the noise pattern is entirely varying only along the V dimension. Any change in U, X, Y, or Z is not involved in generating the pattern. Only the V coordinate causes any variation. Thus, I made a node that produces random values vertically, but constant values horizontally.
Neat huh?
Here's the image with the Fractal_Sum node, a few posts earlier
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Just before I head off to bed, I think that 2008 post is the key to "Basically you manipulate the offsets of any noisy node (FractalSum, fBm, etc.) so that the coordinate is a constant for whatever region you want. The resulting patterns are unpredictable in color but completely controlled in shape.".This was just a quick testto seeif I'm on the right track:
Note: I also tried with the Noise and Cellular node. The Noise node gives odd artefacts,and the Cellular doesn'tseem to work thisway.
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Regarding the shader in the previous post - I was originally using a horizontal plane (not the stack of books), which is why I had a constant plugged into y_scale, and the manipulated u/v texture coordinates plugged into z/x_scale respectively.
With the stack of books, the bottom 32 are mapped to the left side of the UV map,while the top 32 are mapped to the right side,so it all looks correct.
However, I'd forgotten to change the connections, i.e. swap the inputs to y_scale and z_scale.
So I'm slightly puzzled as to why it's working ?
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
Which nodes work and which of x,y,z the constant should be plugged into cropped up again here Using 3D nodes (Cellular) with 2D UV maps ? and are, to are large extent, now understood.
Ish... ;o)
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
The attached image (below) explains what I mean.
I'm probably missing something obvious... as usual !
The 3Dcheapskate* occasionally posts sensible stuff. Usually by accident.
And it usually uses Poser 11, with units set to inches. Except when it's using Poser 6 or PP2014, or when its units are set to PNU.
*also available in ShareCG, DAZ, and HiveWire3D flavours (the DeviantArt and CGBytes flavour have been discontinued).