 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"tree_colormap_temp_file.inc" is the place I composite (all) patterns, ... to
the output pigment.
I directly copy this file from ...which made by myself.
Output pigment is named 'diffuse_pigment'. It has rgb colors. In the future it
is necessary to produce grayscale output for the roughness map, normal map...,
too.
"..._bumps_pattern_detail.inc" prepares the thin pattern, fiber, ... for the
"tree_colormap_temp_file.inc"
You can produce more thin pattern here, using the macro I write
generate_thin_circled_pattern_f_input_t_theta_h(
....
), I only finish this one(in fact two or three, but they appointed by this one)
for generate thin pattern.
You can use any function produced by yourself.
You can change these files above.
Post a reply to this message
Attachments:
Download 'files of the output.png' (141 KB)
Preview of image 'files of the output.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
> this looks like it's going to be a fun tool !
Thomas de Groot <tho### [at] degroot org> wrote:
> Thank you very much indeed. I am truly impressed. As Maurice said: this
> is going to be fun to play with. I shall let you know my thoughts while
> testing this.
>
> --
> Thomas
Thanks two... 'fun' . ..
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The 'macro' which I should introduce is
generate_thin_circled_pattern_f_input_t_theta_h(
first_time, last_time, d_boundary_time0, d_boundary_time1, t_radial_bump_size,
time_node_amount,
bump_size_along_theta, theta_pos_random_factor,
min_h, max_h, d_boundary_h0, d_boundary_h1,
seed_m,
r_vs_t, h_vs_r_ratio
)
It is located at bump_pattern_base_function_macros.inc
The goal of it is to generate thin pattern, just like f_bumps(x,y,z).
But it is on the different coordinate system(I say that 'tree log coordinate' in
this case), this macro just generate an output_f = function(time, theta, h) {
....
}
It generate bumps along theta by generating an position array[seg_amount] during
0~2*pi, it consult the input 'bump_size_along_theta' to determine the
seg_amount, the shorter the bump size, the larger the seg_amount.
'theta_pos_random_factor' controls the randomize of the positions. When it is
zero, the position is equally spaced on theta, when it is 1, the position has
the max randomize.
Post a reply to this message
Attachments:
Download 'generate pattern macro var_theta.png' (38 KB)
Preview of image 'generate pattern macro var_theta.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
'first_time', 'last_time', 'd_boundary_time0', 'd_boundary_time1' define the
boundaries of the pattern on 'time value', you can regarded it as the radial
direct pattern.
't_radial_bump_size' as in attachment picture, unit is year.
'time_node_amount' is because, if it generate only one continuous pattern on
theta, the 'bump_size_along_theta' cannot maintain, the bump_size will get
smaller at the smaller radius. So I generate several patterns. On different
radius, I apply different seg_amount to theta position array[seg_amount]
It is the origin of it needing 'time_node_amount' to determine the amount of
such pattern on different radius. You can set it 3~5 it should sufficient.
Post a reply to this message
Attachments:
Download 'generate pattern macro var_t.png' (38 KB)
Preview of image 'generate pattern macro var_t.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Such design is assumed the ideal situation. In fact, I'm planning to revise it.
It is obvious imperfect along the h-direct, When I ..'veneer' it, it shows no
change pattern (along theta).
Post a reply to this message
Attachments:
Download 'show board2 radiosity.png' (1035 KB)
Preview of image 'show board2 radiosity.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The Java version which I used is Java SE 8 (1.8.0_91) currently. So the version
above it should be acceptable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 27-6-2022 om 17:56 schreef And:
> First release.
Thanks And!
Test version, so I shall not (yet) comment on the visual aspects and so on.
However, one very important thing is the way decimals are written to the
example include files. My system uses 'dots' (example: 3.9432) instead
of 'commas' (example: 3,9432) like is done by your app. I guess that
some countries/systems do so standard, but not all. My system uses
'dots'. If this is an issue for better international use, could you make
this an initial choice to make by the user? Or is there another way to
change this easily?
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 27-6-2022 om 17:56 schreef And:
> > First release.
>
> Thanks And!
>
> Test version, so I shall not (yet) comment on the visual aspects and so on.
>
Thanks for understanding.
> However, one very important thing is the way decimals are written to the
> example include files. My system uses 'dots' (example: 3.9432) instead
> of 'commas' (example: 3,9432) like is done by your app. I guess that
> some countries/systems do so standard, but not all.
I use 'meter' as the length unit, so that output result is caused by my habit.
The dots are decimal points.
I want to ask a question, a number contain commas can be read as 'one' number
correct by POV-Ray?
Can 3,9432 be a number?
> If this is an issue for better international use, could you make
> this an initial choice to make by the user? Or is there another way to
> change this easily?
>
> --
> Thomas
Currently You might need use 'scale' to the pigment to convert it to your
customary unit. I will add a list(menu) to select unit on the "Basic
Profile"(first page) in the future version. But I need time to research this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Excuse me, I upload the same version but compress to the .zip
Post a reply to this message
Attachments:
Download 'wooddesignprogram alpha ver20220627.zip' (987 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"And" <49341109@ntnu.edu.tw> wrote:
> > However, one very important thing is the way decimals are written to the
> > example include files. My system uses 'dots' (example: 3.9432) instead
> > of 'commas' (example: 3,9432) like is done by your app. I guess that
> > some countries/systems do so standard, but not all.
>
> I use 'meter' as the length unit, so that output result is caused by my habit.
> The dots are decimal points.
Units don't appear to be the issue. The representation of decimal fractions is
what Thomas is concerned about.
> I want to ask a question, a number contain commas can be read as 'one' number
> correct by POV-Ray?
> Can 3,9432 be a number?
Nope. That would be a string. AFAIK, all versions of POV-Ray use only numerals
and the "+,-, and ." glyphs to represent numerical values. Formatting those
values using str and probably a macro would be necessary to show the usual
commas between every step of 10^3.
> > If this is an issue for better international use, could you make
> > this an initial choice to make by the user? Or is there another way to
> > change this easily?
> >
> > --
> > Thomas
>
> Currently You might need use 'scale' to the pigment to convert it to your
> customary unit. I will add a list(menu) to select unit on the "Basic
> Profile"(first page) in the future version. But I need time to research this.
I think he means "Is there a way to specify whether to use "," or "." for the
data's output format.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
