 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm trying to freshen up my heightfields to make them a bit more like
terrain. I've seen examples where various packages used erosion to make
more realistic terrain. I (obiously) know what erosion is, how it
works, but HOW THE HECK do you model it mathematicly???? I'm a bit lost
there [smile].
If anyone could provide some pseduo code with what it requires, it would
be greatly appcreciated. I'm am not looking for a POV example, as this
won't be written into POV, but into an external C program. I have also
tried looking at HF-Lab and can't figure out what makes its erosion
engine tick.
Yann
--
--------------------------------------------------------------------
Yann Ramin atr### [at] atrustrivalie euorg
Atrus Trivalie Productions www.redshift.com/~yramin
Monterey High IT www.montereyhigh.com
ICQ 46805627
AIM oddatrus
Marina, CA
IRM Developer Network Toaster Developer
SNTS Developer KLevel Developer
(yes, this .signature is way too big)
"All cats die. Socrates is dead. Therefore Socrates is a cat."
- The Logician
THE STORY OF CREATION
In the beginning there was data. The data was without form and null,
and darkness was upon the face of the console; and the Spirit of IBM
was moving over the face of the market. And DEC said, "Let there be
registers"; and there were registers. And DEC saw that they carried;
and DEC seperated the data from the instructions. DEC called the data
Stack, and the instructions they called Code. And there was evening
and there was a maorning, one interrupt...
-- Rico Tudor
William Safire's Rules for Writers:
Remembe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yann Ramin wrote:
> I'm trying to freshen up my heightfields to make them a bit more like
> terrain. I've seen examples where various packages used erosion to make
> more realistic terrain. I (obiously) know what erosion is, how it
> works, but HOW THE HECK do you model it mathematicly???? I'm a bit lost
> there [smile].
>
> If anyone could provide some pseduo code with what it requires, it would
> be greatly appcreciated. I'm am not looking for a POV example, as this
> won't be written into POV, but into an external C program. I have also
> tried looking at HF-Lab and can't figure out what makes its erosion
> engine tick.
There are some POV examples in these groups from a couple of weeks to a
month back but I can't remember which group/s.
I suppose you would follow the path of a water droplet falling
vertically/other from the sky and taking some soil with it - allowing for
deposition & erosion.
You might try e-mailing the author of HF-Lab & other HF programs that have
this feature to ask the algorithm.
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pabs wrote:
> You might try e-mailing the author of HF-Lab & other HF programs that have
> this feature to ask the algorithm.
I have talked with John Beale in the past and found him talkative and
willing to share info where possible.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yann Ramin wrote:
>
> I'm trying to freshen up my heightfields to make them a bit more like
> terrain. I've seen examples where various packages used erosion to make
> more realistic terrain. I (obiously) know what erosion is, how it
> works, but HOW THE HECK do you model it mathematicly???? I'm a bit lost
> there [smile].
>
> If anyone could provide some pseduo code with what it requires, it would
> be greatly appcreciated. I'm am not looking for a POV example, as this
> won't be written into POV, but into an external C program. I have also
> tried looking at HF-Lab and can't figure out what makes its erosion
> engine tick.
>
I never understood John Beale's code totally, but I think it calculates an
array, where the valuses are equivalent to the uphill area at this point, which
is related to the amount of water flowing there. Usually you are substracting
this array from your terrain.
All this calculates pure water erosion. To create realistic effects, it
requires much smoothing to simulate the flattening of the structures created by
the water over the time.
Maybe you want to check the samples i made for a fast thermal erosion code. One
I posted in p.b.i some time ago. Some more including a sort avi film are on my
pages:
http://www.schunter.etc.tu-bs.de/~chris/erosion1.html
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Maybe you want to check the samples i made for a fast thermal erosion code. One
> I posted in p.b.i some time ago. Some more including a sort avi film are on my
> pages:
>
> http://www.schunter.etc.tu-bs.de/~chris/erosion1.html
Does your method simulate deposition of the eroded material?
-From the avi it does look like it does
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pabs wrote:
>
> Does your method simulate deposition of the eroded material?
> -From the avi it does look like it does
It's not a simulation of a physical move of material, it would never be that
fast then :-) I never checked how the volume of the terrain changes during the
process, but i think it stays quite constant in the avi.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Looked really neat, just seemed a lot more low area fill-in going on than
there was high-point sloughing resulting in a overall rise of the terrain.
But far as how it goes about it looked good top me. Maybe if it were
somehow excavated away in the lowest parts it might be better, as if it's
carried away, rather than stuck in the one region like a bowl formation
does. But I'm just expressing unknowledgeable opinion.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> Looked really neat, just seemed a lot more low area fill-in going on than
> there was high-point sloughing resulting in a overall rise of the terrain.
> But far as how it goes about it looked good top me. Maybe if it were
> somehow excavated away in the lowest parts it might be better, as if it's
> carried away, rather than stuck in the one region like a bowl formation
> does. But I'm just expressing unknowledgeable opinion.
>
> Bob
I'm not sure whether i understood everything you wrote, but right now, the
overall height is always scaled to fit the whole range after each calculation.
As i already said it does not simulate physical processes, even though, you are
probably right, that there are some problems with nearly flat areas like the
bottom of basins. But i think it gets along with local minima much better than
John Beale's Water Erosion, even though you probably cannot compare it.
BTW, the in the avi, there is an additional high peak on the left not visible in
the camera, which affects the overall height of the terrain.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <Chr### [at] schunteretctu-bsde> wrote in
message news:397D49CF.4DFEE6C5@schunter.etc.tu-bs.de...
|
| BTW, the in the avi, there is an additional high peak on the left not
visible in
| the camera, which affects the overall height of the terrain.
Oh, I think that could explain the increasing height at the near corner
then. It just seemed to be expanding upward more than would be feasible for
being only the one major peak degrading. That's all I was talking about
before.
Actually, I like the narrowing channels at the lowest parts, even if there
doesn't appear to be any etching out of them. I think this is what was said
earlier, someone was trying to describe it too.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've always hated heightfields (read: never gotten good with them).
I think humanity would ultimately be served by someone figuring out an
algorithmic, mathematical way to "erode" a smooth rolling isosurface.
Yann Ramin wrote:
> I'm trying to freshen up my heightfields to make them a bit more like
> terrain. I've seen examples where various packages used erosion to make
> more realistic terrain. I (obiously) know what erosion is, how it
> works, but HOW THE HECK do you model it mathematicly???? I'm a bit lost
> there [smile].
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397DA45B.6514AB60@my-dejanews.com>,
gre### [at] my-dejanewscom wrote:
> I've always hated heightfields (read: never gotten good with them).
>
> I think humanity would ultimately be served by someone figuring out an
> algorithmic, mathematical way to "erode" a smooth rolling isosurface.
Maybe some kind of filter for 3df files? You could then use the 3df file
as input for a pigment function for the isosurface.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ugh, that would require me understanding what the heck a 3df is.
;)
Chris Huff wrote:
> In article <397DA45B.6514AB60@my-dejanews.com>,
> gre### [at] my-dejanewscom wrote:
>
> > I've always hated heightfields (read: never gotten good with them).
> >
> > I think humanity would ultimately be served by someone figuring out an
> > algorithmic, mathematical way to "erode" a smooth rolling isosurface.
>
> Maybe some kind of filter for 3df files? You could then use the 3df file
> as input for a pigment function for the isosurface.
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>Maybe some kind of filter for 3df files? You could then use the 3df file
>as input for a pigment function for the isosurface.
>
I tried something but did not succeed. The idea was to take two df3-files
into a hexeditor, chop the header of, replace it with a tga header. Then
take both in ImageMagick and morph. Then do the header trick in the
opposite way for each resulting image.
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397DA95A.B58E927B@my-dejanews.com>,
gre### [at] my-dejanewscom wrote:
> Ugh, that would require me understanding what the heck a 3df is.
Yes...I suppose it would.
A 3df is a 3D Density File, sort of a 3D bitmap.(which I guess would
make POV a 3D vector format) Instead of storing polygons or other
shapes, it stores voxels, the 3D equivalent of a pixel.
POV has the ability to read these files as a pattern, so you can use
them as input for an isosurface. It also has interpolation features
which make lower-resolution 3df files useable.
I am currently working on a Mac modeller for 3df files...I thought this
might be a useful feature for it. The only real problem would be the
size of the file...though it would at least be smoother than a height
field, and could have things like caves.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <8F7CA201Aseed7@204.213.191.228>, ing### [at] homenl (ingo)
wrote:
> I tried something but did not succeed. The idea was to take two df3-files
> into a hexeditor, chop the header of, replace it with a tga header. Then
> take both in ImageMagick and morph. Then do the header trick in the
> opposite way for each resulting image.
Seems it would be easier to just make a program output a stack of tga
files from a 3df file...anyway, what I was thinking of would be a real
3D filter designed to do erosion on a 3df file. Maybe by using some kind
of particle effects to simulate where rain would fall and water would
flow, with each particle carrying some "soil" and depositing it when it
slows down. I've had some practice with particle systems lately. :-)
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> Seems it would be easier to just make a program output a stack of tga
> files from a 3df file...anyway, what I was thinking of would be a real
> 3D filter designed to do erosion on a 3df file. Maybe by using some kind
> of particle effects to simulate where rain would fall and water would
> flow, with each particle carrying some "soil" and depositing it when it
> slows down. I've had some practice with particle systems lately. :-)
>
You must have a really fast computer to suggest those things...
Another nice thing about real 3d-erosion would be that you could easily add
support for layers of different materials with different erodability, you could
also think of tectonics, but i would suggest to by lots of RAM and a really fast
CPU first :-)
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397DB98D.FDD8D770@schunter.etc.tu-bs.de>,
chr### [at] gmxde wrote:
> You must have a really fast computer to suggest those things...
Well, depends on whether or not you consider a 266MHz PowerPC G3 "really
fast". I would call it "fairly fast", and more than adequate for most
uses, but for real number-crunching, you should get a 450MHz G4
Cube...or one of the dual-G4 Power Macs. :-)
> Another nice thing about real 3d-erosion would be that you could
> easily add support for layers of different materials with different
> erodability, you could also think of tectonics, but i would suggest
> to by lots of RAM and a really fast CPU first :-)
*Lots* of ram...since a 3df file is simply 256-bit grayscale, you would
need separate 3df files to specify those other variables. And to get a
large landscape, you would need a fairly high-res landscape file(the
others, like erodability maps, could be much lower resolution).
A 256*64*256 file would equal 4MB...3df doesn't have any compression.
And 512*128*512 would be 32MB. Good thing interpolation is available. :-)
It would help if someone developed a 3D-PNG format...3ng?...though RAM
would still be a problem. I have 96MB, and have bumped into the RAM
barrier a couple times(I have virtual memory set to the minimum, for
speed reasons).
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 25 Jul 2000 10:51:06 -0400, "Greg M. Johnson"
<gre### [at] my-dejanewscom> wrote:
>Ugh, that would require me understanding what the heck a 3df is.
>
>;)
Chris means .df3 files used in the density_file pattern. Skim the
docs, the info is there.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>It would help if someone developed a 3D-PNG format...3ng?
Could you "abuse" animated png's (mng) for that?
Also you can stuff more than one image in a single tga (rl encoded) or
tiff file.
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <gfgrnsof2h6m7rhidfgnu0d91klqc3kr8q@4ax.com>, Peter Popov
<pet### [at] usanet> wrote:
> Chris means .df3 files used in the density_file pattern. Skim the
> docs, the info is there.
Er, yeah, .df3, .3df...
:-)
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
[...]
>
> *Lots* of ram...since a 3df file is simply 256-bit grayscale, you would
> need separate 3df files to specify those other variables. And to get a
> large landscape, you would need a fairly high-res landscape file(the
> others, like erodability maps, could be much lower resolution).
> A 256*64*256 file would equal 4MB...3df doesn't have any compression.
> And 512*128*512 would be 32MB. Good thing interpolation is available. :-)
>
All that is not really effective, because you have to carry the whole "air"
around that is never used.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <8F7CC6C2Fseed7@204.213.191.228>, ing### [at] homenl (ingo)
wrote:
> Could you "abuse" animated png's (mng) for that?
You could...but the file size would probably be bigger than it needs to
be, unless mng supports 256-shade grayscale. And how does it handle the
compression? Are frames compressed individually and stacked together, or
does the compression use info from previous and following frames?
> Also you can stuff more than one image in a single tga (rl encoded) or
> tiff file.
I know about these "stacks", but I don't think the compression is as
efficient as it could be.
It might be better to have a custom format which can handle no
compression, lossless compression, lossy compression(like MPEG), 8-bit
grayscale and 24-bit color. Maybe we could call it 3df. :-)
Or maybe you could just support several animation formats, including MNG
and MPEG.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff-12226F.11302925072000@news.povray.org>, Chris
Huff <chr### [at] maccom> wrote:
> since a 3df file is simply 256-bit grayscale...
I meant 256-shade grayscale, of course. As in 8-bit grayscale. :-)
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397DD493.909A1DC0@schunter.etc.tu-bs.de>,
chr### [at] gmxde wrote:
> All that is not really effective, because you have to carry the whole
> "air" around that is never used.
I'm not sure what you mean...even though it isn't used, you still have
to store it. The "air" is simply any voxel with a density of 0, you have
to store these voxels along with all the others.
An alternative would be to store the coordinates, size, and density of
each voxel. For some files, this would be smaller...but for others, it
would be a lot larger.
A compromise might be to partition the file into cubical chunks, each
one with it's own resolution. That way, large areas of a single value
could be represented as a single voxel, while areas with a lot of
small-scale changes could still be accurately represented. There are
probably better ways to compress the data, though...
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> I'm not sure what you mean...even though it isn't used, you still have
> to store it. The "air" is simply any voxel with a density of 0, you have
> to store these voxels along with all the others.
That's what i meant.
> An alternative would be to store the coordinates, size, and density of
> each voxel. For some files, this would be smaller...but for others, it
> would be a lot larger.
I thought of storing the data in form of "columns" of variable height, but
that's probably very slow and not that easy to handle. Could save a lot of
memory when working with high vertical resolution.
> A compromise might be to partition the file into cubical chunks, each
> one with it's own resolution. That way, large areas of a single value
> could be represented as a single voxel, while areas with a lot of
> small-scale changes could still be accurately represented. There are
> probably better ways to compress the data, though...
>
Sounds much like wavelet-compression, that should also work with 3 dimensions,
but it's probably quite calculation intensive.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>In article <8F7CC6C2Fseed7@204.213.191.228>, ing### [at] homenl (ingo)
>wrote:
>
>> Could you "abuse" animated png's (mng) for that?
>
>You could...but the file size would probably be bigger than it needs to
>be, unless mng supports 256-shade grayscale. And how does it handle the
>compression? Are frames compressed individually and stacked together, or
>does the compression use info from previous and following frames?
Sorry, only a link to answer your questions http://www.libpng.org/pub/mng/
I made a 256 colour mng, it was smaller than the animated gif.
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397DDEF9.7680CA04@schunter.etc.tu-bs.de>,
chr### [at] gmxde wrote:
> I thought of storing the data in form of "columns" of variable
> height, but that's probably very slow and not that easy to handle.
> Could save a lot of memory when working with high vertical
> resolution.
Though not the most efficient method, and mainly useful for
height-field-like voxel structures, that should be quite possible...
> Sounds much like wavelet-compression, that should also work with 3
> dimensions, but it's probably quite calculation intensive.
I don't think this is anything like wavelet compression, which I think
is based on fourier transforms. I think this would have more in common
with run-length encoding. Basically, divide the voxel data up into
cubes. If the voxels in a cube vary by less than a certain amount, the
resolution within that cube is reduced or the voxels are replaced with a
single, larger voxel. If more than that amount, all of the data is
retained, or maybe the cube gets subdivided.
This would definitely be more computationally expensive than
uncompressed files or your "column" encoding, but could be quite
efficient for many structures.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My (perhaps self-limiting) philosophy is: why use a paint program when you
can use a vector one, why use a vector program when you can do 3d, why use
a heightfield when you can use an isosurface. The work need not be
re-created from scratch if another point of view or higher resolution is
required.
Chris Huff wrote:
> In article <397DA95A.B58E927B@my-dejanews.com>,
> gre### [at] my-dejanewscom wrote:
>
> > Ugh, that would require me understanding what the heck a 3df is.
>
> Yes...I suppose it would.
> A 3df is a 3D Density File, sort of a 3D bitmap.(which I guess would
> make POV a 3D vector format) Instead of storing polygons or other
> shapes, it stores voxels, the 3D equivalent of a pixel.
> POV has the ability to read these files as a pattern, so you can use
> them as input for an isosurface. It also has interpolation features
> which make lower-resolution 3df files useable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397EF8DB.340374FD@my-dejanews.com>,
gre### [at] my-dejanewscom wrote:
> My (perhaps self-limiting) philosophy is: why use a paint program
> when you can use a vector one, why use a vector program when you can
> do 3d, why use a heightfield when you can use an isosurface. The
> work need not be re-created from scratch if another point of view or
> higher resolution is required.
Mostly I agree, and df3's are even less useful with the blob pattern
available(though sometimes considerably more compact). However, they do
have certain uses, such as the ability to edit specific voxels,
possibilities for external modellers, being a useful format for certain
kinds of data that can't easily be converted to a "vector" format(like
certain volumetric data, MRI scans, etc), the ability to apply filters
to the data, etc.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And I guess NASA is too lazy to post the isosurface equations for
Mars.............
Chris Huff wrote:
> Mostly I agree, and df3's are even less useful with the blob pattern
> available(though sometimes considerably more compact). However, they do
> have certain uses, such as the ability to edit specific voxels,
> possibilities for external modellers, being a useful format for certain
> kinds of data that can't easily be converted to a "vector" format(like
> certain volumetric data, MRI scans, etc), the ability to apply filters
> to the data, etc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
