 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/8/2016 5:14 PM, Bald Eagle wrote:
> Stephen <mca### [at] aol com> wrote:
>
>>> Yes. I am (usually) a big fan of checklists.
>> Unless something is going to go bang. I am not, I am afraid.
>
> For a while, I was using some organoboranes, organoaluminum, and organozinc
> reagents that were air-sensitive and spontaneously pyrophoric.
> So there was great potential for "pop" "Whooooooosssssh" "BANG"
>
Rather you than me. ;)
> Others were .... less safety conscious - and it showed.
>
>
I worked on offshore drilling rigs as an electronic engineer for several
years.
Q. How do you tell if it is a driller ordering a round of drinks?
A. He will show the barman all his fingers and say three pints of beer.
(Really hard to tell a visual joke on paper.) :)
>> The idea is to add dirt/staining to edges, junctions of surfaces etc.
>> You might be interested in this thread.
>>
>>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4aa83e6a37d8ab92c83e2c410%40news.povray.org%3E/?mtop=3233
> 17
>
> Oooh, yes. That must be the "Edouard Poor" I have heard so much about in
> related threads. I'll definitely have to check those macros out. They could
> add as much or more as radiosity does to a scene. :)
>
>
Thomas has used it to good effect. I have used it.
>> *.obj is the geometry file, *.mtl is the textures referenced by the obj
>> file. Both are text and human readable.
>
> Got it. It's been a while.
>
And there are so many TLA (three-letter acronyms) :)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Alain <kua### [at] videotronca> wrote:
>
>> Sory, it's just not possible. DF3 support 1, 2 or 3 bytes per voxel, but
>> always in a single channel gray levels.
>
> Given what Stephen resorts to doing, I thought that might be the case.
>
> BUT - I also thought that perhaps if there were a way to recolor the DF3 befor
> saving, then the realistic RBG values could be _encoded_ into that false color
> in such a way that they could be extracted back out of the gray value.
>
How can you recolor before saving when the format only support discrete,
single component, scalar values? That's just not possible.
Remember that DF3s have no concept of colour at all. It's strictly a
list of 1 dimension values.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotronca> wrote:
> How can you recolor before saving when the format only support discrete,
> single component, scalar values? That's just not possible.
>
> Remember that DF3s have no concept of colour at all. It's strictly a
> list of 1 dimension values.
Let me give a different example -
If there is a grayscale value, then that must have some range or depth - how
many values?
If it's like a pattern{}, then you can give it a color_map{}.
My idea here, is instead of having the grayscale represent a range of gray from
0 to Max with 1-unit intervals, have it represent an RGB scale from 0 to Max
_STEP 3_. It's a lot rougher, but it encodes full color.
Let's say you've got the usual 0-255 values.
That's 8 bits.
pow(2, 8) = 256
let's use 6 of those bytes, 2 for each color channel
granted, that only gives you 4 levels for each channel, but it's rgb - the data
is there.
The trick is getting more than those 4 levels for each channel squeezed into
those 8 bytes.
But I still think it's a better, faster workflow than what Stephen's currently
doing.
I'm sure some very clever folks have ways that can use 8 bits much more
efficiently to store more data.
There certainly seem to be computer-sciency types who have some ideas:
http://stackoverflow.com/questions/3499444/compress-two-or-more-numbers-into-one-byte
http://mathoverflow.net/questions/69244/encoding-n-natural-numbers-into-one-and-back
https://en.wikipedia.org/wiki/Z-order_curve
https://www.google.com/#q=how+to+encode+data+into+one+number
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It also occurred to me that one probably doesn't even need to cover the whole
range of RGB values - only the range that's being used, or is significant.
If only certain rgb values are being used, then that a smaller range, and those
few subdivisions represented by the bytes the you have to work with now
represent a much finer scale.
It occurs to me on writing this, that it may be more effective to just ditch RGB
altogether and "encode" the colors in HSV. Throw out S and V, and just assume
they're both 1, and that leaves you with 360 values.
That gives you a "fineness" of 1.41, which I'm sure is perfectly adequate for
the purpose at hand.
We have some very good people who write POV-Ray source code, and so it would be
a wonderful thing to be ahead of everyone else and have a rapid way of rendering
"full-color" df3 voxels.
The only trick then is to figure out how to get the generating software to write
a scaled hue value rather than a greyscale value.
Sound plausible?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And then there's THIS:
http://news.povray.org/povray.binaries.utilities/thread/%3C4a2870e2%40news.povray.org%3E/?ttop=398992
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8-8-2016 16:12, Bald Eagle wrote:
> I missed the whole proximity pattern phase of interest and development.
> No real idea of what they are, what they do, or how they work.
There are a couple of methods around the place, Sam Benge, Edouard Poor
for the most notable. Personally, I much prefer Edouard's method and
have used it extensively. I developed a HowTo from it and maybe I can
make you happy with that some day? :-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/9/2016 7:42 AM, Thomas de Groot wrote:
> maybe I can make you happy with that some day? :-)
It would save me some time relearning it. :)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9-8-2016 9:17, Stephen wrote:
> On 8/9/2016 7:42 AM, Thomas de Groot wrote:
>> maybe I can make you happy with that some day? :-)
>
> It would save me some time relearning it. :)
>
I am going to verify if everything is straightforward and then post the
needed files...
[looks for a round tuit under desk...]
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/7/2016 11:26 PM, Alain wrote:
> Here are the default vbalues :
> method 3
> samples 10
> intervals 1 // Don't increase !
>
> The default code from Bishop mostly repeat the actual defaults values.
> That effectively make then into "no operation" code.
>
> Even on the fastest machine, using intervals >1 is a serious performance
> killer.
Thanks Alain,
B3D sets the default value for intervals to 10. We must have missed that
during testing.
I have created a default texture in the new scene template which I will
copy instead of creating from the menu.
(Thinking back. This must be the source of many of my problems in the past.)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16-08-10 à 04:01, Stephen a écrit :
> On 8/7/2016 11:26 PM, Alain wrote:
>> Here are the default vbalues :
>> method 3
>> samples 10
>> intervals 1 // Don't increase !
>>
>> The default code from Bishop mostly repeat the actual defaults values.
>> That effectively make then into "no operation" code.
>>
>> Even on the fastest machine, using intervals >1 is a serious performance
>> killer.
>
>
> Thanks Alain,
> B3D sets the default value for intervals to 10. We must have missed that
> during testing.
> I have created a default texture in the new scene template which I will
> copy instead of creating from the menu.
> (Thinking back. This must be the source of many of my problems in the
> past.)
>
IIRC, intervals 10 is the default for method 1 and 2. Also, method 1 was
the default before version 3.5.
It's common for pre version 3.5 scenes and include to set intervals to
larger values than that. It's also common for external utilities made
during that time to have similar settings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
