 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Galvin <tom### [at] imp org> wrote in message
news:Xns94A4781ED35AFtomatimporg@203.29.75.35...
>
> Blender is available for Windows, Mac OS X, Linux, Solaris ....
>
Yes, but when I tried it previously, it was designed for 3 button mouse,
which I don't have, and Windows doesn't emulate like Linux does. Made the
already annoying interface even more frustrating...
Besides, my goal is to get all of my tools moved to Linux, so I'm not that
interested in the Windows version at this point. (And the main reason I
haven't already registered Terragen...)
RG
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <gitran_nospam_@wanadoo.fr> wrote in message
news:4049194f$1@news.povray.org...
> The big remaining issue for hobbyists, however, is uv-mapping. AFAIK there
> is no free uv-mapping tool allowing real-time 3D painting and some
> automatisation for vertex unwrapping (such as the expensive Bodypaint).
> Until we have such a tool, mapping will remain a limitation for mesh
users.
Recently ran across a uv-mapping program called ManifoldLab, (go here:
pub58.ezboard.com/bggaliens )
Haven't had time to fully explore it yet, but it looks like it has a lot of
automatisation and flexibility, and is actively being developed so new
features are being added frequently. It's a java app so should run on most
platforms.
RG
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> in news:40479763@news.povray.org Jim Charter wrote:
>
>
>>[...] and what tools are you using?
>
>
> For me an interseting thing with mesh2 is that it is easier to create
> complex mesh' by using macros within POV-Ray SDL.
>
> Ingo
*easier* is a fairly big leap for me.
I saw Mike William's code for writing to mesh2 but I haven't digested it
yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"gonzo" <rgo### [at] lansetcom> wrote in news:404a2b58$1@news.povray.org:
>
> Yes, but when I tried it previously, it was designed for 3 button
> mouse,
>
You can pick up one of those for the price of a Mocha frappuccino ;)
--
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:404a7076$1@news.povray.org Jim Charter wrote:
> *easier* is a fairly big leap for me.
>
easier in the sense that the mesh2 object is very close to arrays and that
the output of macros that generate vertices will generaly be arrays. So if
you keep some structure in your generation macro it needs relative little
code to turn it into a mesh2. My first versions of the makemesh macro
wrote mesh{} and was quite a bit longer than the current one.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo wrote:
> in news:404a7076$1@news.povray.org Jim Charter wrote:
>
>
>>*easier* is a fairly big leap for me.
>>
>
>
> easier in the sense that the mesh2 object is very close to arrays and that
> the output of macros that generate vertices will generaly be arrays. So if
> you keep some structure in your generation macro it needs relative little
> code to turn it into a mesh2. My first versions of the makemesh macro
> wrote mesh{} and was quite a bit longer than the current one.
>
> Ingo
I'll take a closer look. There are definitely some interesting
possibilities there I think.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> But now, the current machines have enough RAM to digest gigantic meshes
> without complaining so that primitives have become much less competitive.
> This is why, for instance, my Maketree objects are no longer interesting,
> since we have POV-Tree, which exports in mesh (with a better algorithm) and
> allows the creation of entire forests thanks to mesh instanciation.
>
This concept still confuses me.
//case 1: mesh instantiation:
//create tree
#declare SomeTree =
mesh {
triangle {}
triangle {}
triangle {}
...
texture T
}
//create forest
LOOP 10000 TIMES
object { SomeTree translate RandomLocation }
ENDLOOP
//case 2: primitive instantiation
//create tree
#declare SomeTree =
union {
cone {}
sphere {}
triangle {}
...
texture T
}
//create forest
LOOP 10000 TIMES
object { SomeTree translate RandomLocation }
ENDLOOP
How is it that case 1 gets a performance/memory gain and case 2 doesn't?
Especially since, as I found out recently, every intersection of a mesh
element spawns a texture calculation anyway, up to a limit of 100.
> The big remaining issue for hobbyists, however, is uv-mapping. AFAIK there
> is no free uv-mapping tool allowing real-time 3D painting and some
> automatisation for vertex unwrapping (such as the expensive Bodypaint).
> Until we have such a tool, mapping will remain a limitation for mesh users.
>
I take it that real-time 3D painting obviates the need for uv coordinate
unwrapping by hand?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:404a2ce2@news.povray.org...
> Recently ran across a uv-mapping program called ManifoldLab, (go here:
> pub58.ezboard.com/bggaliens )
I'll have a look, thanks.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:404bbcb8$1@news.povray.org...
> How is it that case 1 gets a performance/memory gain and case 2 doesn't?
> Especially since, as I found out recently, every intersection of a mesh
> element spawns a texture calculation anyway, up to a limit of 100.
This is something that should be asked to programmers... There's a thread
somewhere about this issue, and IIRC someone from the POV-Team agreed that
the other primitives should be instanciated as well. There's also the issue
that it's not possible to instanciate a mesh independently of the textures.
> I take it that real-time 3D painting obviates the need for uv coordinate
> unwrapping by hand?
Real-time 3D painting and automatic unwrapping are two different features.
In 3D painting, one paints the model through a 3D interactive view, just
like one would do in real life. UV Mapper Pro lets you switch between the 3D
view and the 2D painting program but it's not quite the same.
Automatic unwrapping tries to guess the best possible uv layout for a given
model in order to avoid distortions. It's still a tough job anyway. To be
fair, I still have to learn Bodypaint so I'm not completely aware yet of
what it can or cannot do, and how difficult it is...
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> Real-time 3D painting and automatic unwrapping are two different features.
Okay fair enough, I really wasn't confused about that but as I try to
explain myself further, I see that my question was more complex than it
seemed at first.
In the whole uvmapping process, is about relating 2d information, a
pattern of colors, to 3d information, a surface which carves through
space, via the use of intermediary 2d uv coordinates. In this way the
3d surface can be colored with a specific pattern. Techniques and the
interfaces which support them, traditionally try to picture the 3d
surface flattened onto a 2d uv register in the form of a pattern or
template. But doing this by simply collapsing one of the 3 dimensions
usually leads to a tangled pattern of mappings, between vertices and uv
coordinates, which then corresponds awkwardly to any coherent pattern of
colors.
So instead, the 3d surface is "unwrapped" by splitting edges
systematically along well chosen lines, so that the surface being
colored can be spread out, so to speak, onto the 2d register in the most
coherent way. Now the pattern of color can be more easily corresponded
to the pattern of uv coordinates, and hence mapped to the 3d surface.
This unwrapping process is supported by tools native to modellers or
independently such as uvmapper, and can support processes that are
'manual' and 'automated' to varying degrees. Some strategies for
splitting up the 3d surface and unwrapping it onto the 2d uv register
are so complex as to be only possibly in an automated way. This is what
I understand by the term "auto unwrap". Other strategies involve an
automated first guess at what the flattened pattern might be, and then
the tool supports further 'unwrapping' of the surface, by allowing the
adjustment of the positions of the 3d vertices on the uv register,
'manually'. Either way this whole approach might viewed as bringing the
3d information to the 2d information.
> In 3D painting, one paints the model through a 3D interactive view, just
> like one would do in real life.
Which, as I picture it, is like unwrapping in reverse. Again you are
mapping from a 2d space to a 3d space but in this case the "2d"
information, the pattern of the colours, is corresponded to the 3d
information, the pattern of the vertices in space, through automated
support of a manual process (painting).
So my question was, since I have never had any experience with such a
tool first hand, does it indeed obviate any need for manually
rearranging vertex mappings on a uv template, such as we get involved in
when using uvmapper? If so, it would seem to be a real productivity
boost. Basically I was just ooing and aweing.
-Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
