This month's PC Pro has a free full version of Amapi (I can't remember which
version - sorry).

As far as I can tell, it is the complete program without restrictions, and has a
full range of import/export plug-ins.

Anyone know much about Amapi?

--
#macro A(V,B,C,R)#while(B-256)#if(V-128/B>=0)sphere{0,.5translate<C-4R-1,9>
pigment{rgb<1-C/8R/2C/8>}}#local V=V-128/B;#end#local B=B*2;#local C=C+1;#
end#end A(234,1,0,2)A(85,1,0,1)A(81,1,0,0)light_source{-5 1}//Tom Melly

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> a écrit dans le message de news:
3e9e625f$1@news.povray.org...

> Anyone know much about Amapi?

I have (and used) a previous version, also free and uncrippled.
As always, some people do like it and make nice things with it.
I did find the interface horrible, a case example of how apparently smart
and innovative interface design can turn out to be just dumb and clumsy
(I'll rant about this some day as it's quite common, particularly in
free/low-cost 3D modellers).

G.
--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> "Tom Melly" <tom### [at] tomandlucouk> a écrit dans le message de news:
> 3e9e625f$1@news.povray.org...
>
> > Anyone know much about Amapi?
>
> I have (and used) a previous version, also free and uncrippled.
> As always, some people do like it and make nice things with it.
> I did find the interface horrible, a case example of how apparently smart
> and innovative interface design can turn out to be just dumb and clumsy
> (I'll rant about this some day as it's quite common, particularly in
> free/low-cost 3D modellers).

I too have tried a free uncrippled version of Amapi over a year ago.
I didn't like the interface much either but luckily there's always Wings3d
;)

--
-Jide

Post a reply to this message

"Jide" <jid### [at] kotisoonfi> wrote in message
news:3e9ecb22@news.povray.org...
> Gilles Tran wrote:

> > I did find the interface horrible, a case example of how apparently smart
> > and innovative interface design can turn out to be just dumb and clumsy
> > (I'll rant about this some day as it's quite common, particularly in
> > free/low-cost 3D modellers).
>
> I too have tried a free uncrippled version of Amapi over a year ago.
> I didn't like the interface much either but luckily there's always Wings3d
> ;)
>

Any worse the TrueSpace? (no, surely that's not possible).

I can't help but wonder whether the whole principle of using a mouse to build 3d
objects is basically flawed. Poser, for example, is a lot easier to use IMHO
when you give up trying to drag limbs about with the mouse* and use the dials
instead.

* well, unless your aim is to create some kind of genetically deformed alien
undergoing a cruel and unusual torture.

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e9e625f$1@news.povray.org...
>
> Anyone know much about Amapi?
>

A rather vague question - I like using the pov SDL directly, but, for example, I
like poser since I accept that there is no way I'm going to be able to code
realistic figures without it.

So... what will Amapi allow me to do that I couldn't do with the SDL? (or at
least not realistically).

Post a reply to this message

In article <3e9ed72c$1@news.povray.org>, tom### [at] tomandlucouk says...
> "Jide" <jid### [at] kotisoonfi> wrote in message
> news:3e9ecb22@news.povray.org...
> > Gilles Tran wrote:
> 
> > > I did find the interface horrible, a case example of how apparently smart
> > > and innovative interface design can turn out to be just dumb and clumsy
> > > (I'll rant about this some day as it's quite common, particularly in
> > > free/low-cost 3D modellers).
> >
> > I too have tried a free uncrippled version of Amapi over a year ago.
> > I didn't like the interface much either but luckily there's always Wings3d
> > ;)
> >
> 
> Any worse the TrueSpace? (no, surely that's not possible).
> 

Umm. If I remember rightly, yes it is worse than TrueSpace, worse some 
object types (like NURBS) couldn't be used with some tools or converted 
into a form that could be worked with using those tools. This quirk 
resulted in my jumping to several other apps before finally deciding that 
I didn't know any of them well enough to do what I wanted. However, it is 
better than some others, so I have Amapi on the launchmate bar I have 
used for years, along with 3D Canvas (which gasp!! actually loads DXF 
objects as individual and 'visually unique' meshes, instead of lumping 
them all into one huge mesh like some do), Hamapatch, Moray (really need 
to either get the non-demo or maybe buy Rhino instead..), Poser and an 
old copy of Breeze Designer.

In general.. Amapi's problem is that they supply very nice tools and 
object types, but ignore the traditional multiple view style interface 
and manipulation methods that most usable programs have in favor of a 
single view and really hard to use one. TrueSpace does much the same, but 
it at least lets you easily change viewing angles, etc. Amapi is 
'supposed' to, but when rotating things or attempting to adjust view it 
can be sluggish, unpredictable or just plain refuses to do what you want 
it to. A major pain in the rear to work with.

> I can't help but wonder whether the whole principle of using a mouse to build 3d
> objects is basically flawed. Poser, for example, is a lot easier to use IMHO
> when you give up trying to drag limbs about with the mouse* and use the dials
> instead.
> 
Hadn't thought of the dials, but Poser bugs the heck out of me anyway. 
Why exactly for instance don't even the standard models contain 
constraint information to prevent you from turning an ankle around 180 
degrees from normal? I would rather see someone eventually come up with 
something with Poser like features and some way to 'easily' model and 
define morph data, so you can create something more detailed by altering 
the model in a useful way (I.e. changing general distance between the 
eyes, actual shape of a nose, etc.) and not have to hack the files to add 
morphs for what should be built into the dang thing.

The first time I tried using it my reaction was, 'Gee this is annoying to 
use. I wonder how much a real program like cosmetic surgeons use would 
cost and if -it- could export to a useful format.' Poser was quite 
disappointing and far more annoying than any 'real' modeller I have ever 
seen.

However, you may be right about mice. The main issue as I see it is that 
way back in the days of Autocad someone thought, 'Heh lets add a third 
button to make it easier to access some options.' So, how many 3 button 
mice did you see? Now practically every mouse has at least three (even if 
one is 'under' the scroll wheel), but you are lucky if so called 
professional modellers recognize that button for anything. They also 
ignore the mouse wheels, never mind the fact that using it with the mouse 
movement would give you 3 axis. Hmm.. Somehow that sounds familiar, but I 
can't imagine what 'use' it would have in the 3D app. lol You shouldn't 
blame stupidity and bad design for why it is hard to build things in 
these programs. ;)

But one should not despair, some people have gotten fed up with this 
silliness and have started building more accurate means to do 3D. They 
only work with applications that support them and currently probably cost 
$5,000-$10,000 dollar a piece for something that is little more than a 
mouse that they gutted the scrolls and buttons out of and rearranged so 
they work better, but won't be affordable for most people for years if 
ever. Realizing the ridiculous price tag on these sorts of things, most 
people designing new programs are trying to reinvent the reflective 
sphere by coming up with new, innovative and often impractical or just 
plain dysfunctional interfaces. Such is the world of copyright and 3D 
technology. ;)

> * well, unless your aim is to create some kind of genetically deformed alien
> undergoing a cruel and unusual torture.
> 
Exactly, but then again... At least it 'might' look unique, but I doubt 
it. ;) lol

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> a écrit dans le message de news:
3e9ed72c$1@news.povray.org...
> I can't help but wonder whether the whole principle of using a mouse to
build 3d
> objects is basically flawed.

Well, my reference in 3D modelling is Rhino, which I have always found to be
one of the most intuitive piece of software ever (among complex ones of
course).
Often, it doesn't take much actually, and it's not even about the 3D aspect
itself, but just respecting some common conventions - or at least some
logic - about selecting, dragging, copying, pasting and deleting things, or
using some recognisable icons for usual tasks etc. The worst offender was
the very first version of Blender: some users (including me) couldn't figure
out how to quit the application and the only solution was to crash it.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Tom Melly wrote:

> So... what will Amapi allow me to do that I couldn't do with the SDL? (or
> at least not realistically).

I don't know Amapi (just tried it a view month ago) but generally a modeler 
will allow you to make organic and / or realistic looking objects. You 
can't do that with POV-Rays SDL. Most images posted at p.b.i are nice, some 
are quite impressive, but none are really realistic. In my opinion the SDL 
is not very well suited to build a scene. Not worth mentioning that this is 
a very unnatural way to create something. So if you just want to create 
some kind of 'interesting' images, SDL is okay. If your goal is realism, 
you should forget it.
You mentioned to code realistic figures. There are lot's of other things you 
can't really do with SDL.

-- 
http://www.render-zone.com

Post a reply to this message

in news:3e9efa16@news.povray.org Andreas Kreisig wrote:

> I don't know Amapi (just tried it a view month ago) but generally a
> modeler will allow you to make organic and / or realistic looking
> objects. You can't do that with POV-Rays SDL.

I have to disagree! Anything can be done in SDL, if you have the right
macros and a lot of time. On the other hand the same can be said of
doing something simple in SDL that turns out to be something complex
with a modeller. There actually may be a reason for the fact that more 
and more GUI modellers also incorporate a scripting language.

> Most images posted at
> p.b.i are nice, some are quite impressive, but none are really
> realistic.

Please define realistic.

> In my opinion the SDL is not very well suited to build a
> scene. Not worth mentioning that this is a very unnatural way to
> create something.

Yet again I have to disagree. SDL can be seen as a modelling language
or as an intermediate format between a GUI and the raytracer. If you
export your Maya models to POV-Ray, however "realistic" they are,
you're still using SDL. 

> So if you just want to create 
> some kind of 'interesting' images, SDL is okay.If your goal is
> realism, you should forget it.

Again, define realisim.


Ingo

ps. I'm not advocating the pure use of SDL here, POV-Ray IMO is 'just' a
tool to get a result. To get that result I may, or may not, use other
tools. And realism is IMO not the holy grail of graphics, ever seen a 
negative light source in reality. No? Yet in POV-Ray you can use them.

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3e9e625f$1@news.povray.org...
> This month's PC Pro has a free full version of Amapi (I can't remember
which
> version - sorry).
>
> As far as I can tell, it is the complete program without restrictions, and
has a
> full range of import/export plug-ins.
>
> Anyone know much about Amapi?

Get it if you can. Interface is extraordinary, but it's a
powerfull  modeler. It was in version 3, also, when I first tried it. Beside
NURBS, it support subdividion surfaces, probably the best way for organic
shapes today. As I can see from their site, version 7 can have a clasic
interface.
Well, as i can see, you need some extra tools for another half of work, uv
mapping, suggested tool is UV mapper - this isn't good, really.

Blender have some nice things about subdividion surfaces, and modeling at
all (automatic creation of surfaces between objects), but don't have
undo-redo functions, and have a weak export.

Metasequia ( http://www21.ocn.ne.jp/~mizno/ ) is one of the best tools for
polygons at all, subdivdion surfaces, UV-mapping, but the only educational
version is available outside of Japan, with some export restrictions, for
formats like a 3ds, LWO, etc, but you can export UV-mapped models to
DirectX, and toPOV-Ray through 3d win. Complete, customizable interface is
available in English, but docs are not - however, it's enough intuitive. I
think there are some plugins for uv-mapped POV export, today.

HamaPatch is a powerfull bezier patch modeler, but UV mapping works only
with direct POV bezier patch export, which isn't smooth as exported meshes
in POV.

Some most important modeling things, probably, are: easy adding or removing
elements from your model, support for hardware accelaration, symetrical
modeling, and UV mapping editor. Only Metasequoia can do all of these
things, between mentioned modelers.

Some of free or cheap modelers are equaly powerfull as a high-ends 3d's,
esspecialy in cases of organic modeling. Subdividion surface models can be
exported and animated almost everywhere.

For organic models, POV-Ray SDL is, in my opinion, just a good toy for
spending time.
Anto
http://www.matkovic.com/anto

Post a reply to this message

Andreas Kreisig wrote:
 > Tom Melly wrote:
 >
 >
 >> So... what will Amapi allow me to do that I couldn't do with the
 >> SDL? (or at least not realistically).
 >
 >
 > I don't know Amapi (just tried it a view month ago) but generally a
 > modeler will allow you to make organic and / or realistic looking
 > objects. You can't do that with POV-Rays SDL. Most images posted at
 > p.b.i are nice, some are quite impressive, but none are really
 > realistic. In my opinion the SDL is not very well suited to build a
 > scene. Not worth mentioning that this is a very unnatural way to
 > create something. So if you just want to create some kind of
 > 'interesting' images, SDL is okay. If your goal is realism, you
 > should forget it. You mentioned to code realistic figures. There are
 > lot's of other things you can't really do with SDL.

I'm much more mathematically inclined than artistically, so I really
like positioning object by co-ordinates.  I cannot understand graphing
applications (even 2d ones) that don't allow that.  If it doesn't, how
can you make something as simple as a bullseye, where you need several
concentric circles with a common center?

-- 
Tom A.
"I've got the whole world
In my hands" - John, 3 year old Megalomaniac

Post a reply to this message

ingo wrote:

> in news:3e9efa16@news.povray.org Andreas Kreisig wrote:
> 
>> I don't know Amapi (just tried it a view month ago) but generally a
>> modeler will allow you to make organic and / or realistic looking
>> objects. You can't do that with POV-Rays SDL.
> 
> I have to disagree! Anything can be done in SDL, if you have the right
> macros and a lot of time. On the other hand the same can be said of
> doing something simple in SDL that turns out to be something complex
> with a modeller. There actually may be a reason for the fact that more
> and more GUI modellers also incorporate a scripting language.

In fact you really need a lot of time. But most images made with SDL are 
somewhat geometrical. Scripting languages in GUI modelers have been used to 
add modeling features or small tools. No one will use it to model something 
with it. Okay, sometimes SDL may be faster when the object you want to make 
is based on mathematical algorithms.

>> Most images posted at
>> p.b.i are nice, some are quite impressive, but none are really
>> realistic.
> 
> Please define realistic.

A view examples: with a lot of patience you can make something like a car, 
but you're not able to make a Porsche 911 or a VW Golf or whatever. You can 
make something like a bottle, but it's very hard to make a Jack Daniels 
bottle. You can try to make a human head but that's nearly impossible with 
SDL. Most SDL based images I saw in the past are rather simplyfied (anyway 
they're nice but that's not what I want to point out).

>> In my opinion the SDL is not very well suited to build a
>> scene. Not worth mentioning that this is a very unnatural way to
>> create something.
> 
> Yet again I have to disagree. SDL can be seen as a modelling language
> or as an intermediate format between a GUI and the raytracer. If you
> export your Maya models to POV-Ray, however "realistic" they are,
> you're still using SDL.

Yes, the informations will be stored into mesh2 format. From this point of 
view SDL is an interface like you mentioned it. But it's not very usefull 
when you want to use it as a modelling language (depending on what you want 
to do with it, of course).

> ps. I'm not advocating the pure use of SDL here, POV-Ray IMO is 'just' a
> tool to get a result. To get that result I may, or may not, use other
> tools. And realism is IMO not the holy grail of graphics, ever seen a
> negative light source in reality. No? Yet in POV-Ray you can use them.

You're right regarding realism. On the other side POV-Ray is an outstanding 
Raytracer (I really love it) wich is able to create photorealistic images, 
but most of the images made with it are ... chrome balls on checkered 
floors in all variations. Realism is not the holy grail but it's one of the 
most ambitious chalanges in CG. POV-Ray can do that but you can't reach it 
when you only use the SDL. You definitive need other tools.
Well, there're some people who can do fantastic things with SDL but they've 
years of experience and often third party tools. I'm too unpatient for that 
and bevor I waste my time to learn the SDL en detail to make some balls or 
cones I rather use Blender. :)

Regards,
Andreas

-- 
http://www.render-zone.com

Post a reply to this message

in news:3e9f3175@news.povray.org Andreas Kreisig wrote:

> In fact you really need a lot of time. But most images made with SDL
> are somewhat geometrical. 

Have a look at the results you can achieve with TomTree or Stricia, 
nothing geometrical there.

>> Please define realistic.
> 
> [...] You can try to make a human head but
> that's nearly impossible with SDL. Most SDL based images I saw in the
> past are rather simplyfied (anyway they're nice but that's not what I
> want to point out). 

How many hours did it take DAZ to create Vicky? Does she look realistic?


Ingo

Post a reply to this message

On Thu, 17 Apr 2003 20:15:16 +0200, "Gilles Tran" <tra### [at] inapginrafr>
wrote:

>Well, my reference in 3D modelling is Rhino, which I have always found to be
>one of the most intuitive piece of software ever (among complex ones of
>course).

Ditto that. The curious thing is, Rhino started out as an AutoCAD
plug-in and this is evident everywhere. It has kept all of the AutoCAD
good points in terms of interface (command line, object snapping &
extending etc.) but has gone to a completely new level of useability
by introducing new and logical elements which AutoCAD has never had
and will probably never have (it's too darn conservative).

AutoCAD is still better for drawing and sketching, though, but of
course that's what it was intended to do in the first place. That's
why I always model in Rhino and export to AutoCAD for the engineering
drawing when I make some design (like my current loudspeaker-to-be).


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Fri, 18 Apr 2003 01:04:12 +0200, Andreas Kreisig <and### [at] gmxde> wrote:
> A view examples: with a lot of patience you can make something like a car, 
> but you're not able to make a Porsche 911 or a VW Golf or whatever.

http://news.povray.org/povray.binaries.images/19709/127888/MyCar.jpg
http://news.povray.org/povray.binaries.images/30145/214068/recar3dc5.jpg
http://news.povray.org/povray.binaries.images/22626/156738/susp.jpg
http://news.povray.org/povray.binaries.images/30945/220060/FORDTRCK.jpg
http://news.povray.org/povray.binaries.images/31112/221106/WALL.jpg

> You can 
> make something like a bottle, but it's very hard to make a Jack Daniels 
> bottle.

Have you seen kitchen images from JRG ?
http://news.povray.org/povray.binaries.images/21949/148872/spezie.jpg
http://news.povray.org/povray.binaries.images/22917/159099/forno.jpg
http://news.povray.org/povray.binaries.images/29029/205449/vaporeEfuoco.jpg
http://news.povray.org/povray.binaries.images/21145/141194/t_b.jpg
http://news.povray.org/povray.binaries.images/19254/124775/waxscatt.jpg

Have you seen images from Jaime ?
http://news.povray.org/povray.binaries.images/27109/191537/balanza-6.jpg
http://news.povray.org/povray.binaries.images/21968/149037/bolts.jpg
http://news.povray.org/povray.binaries.images/20868/138290/office.jpg

> Most SDL based images I saw in the past are rather simplyfied (anyway 
> they're nice but that's not what I want to point out).

Oh sure, I can make a scene like
http://10best.raytrace.com/short2/ks8_800.jpg
But I can also make something like
http://10best.raytrace.com/short2/ks9_800.jpg
http://10best.raytrace.com/short2/ks7_800.jpg
http://10best.raytrace.com/short/ks3_800.JPG
http://10best.raytrace.com/short/ks2_800.JPG
How many clicks will you use in modellers to duplicate these scenes? All those
were created with less than 500 characters.

As Ingo pointed out POV is just one of tools used to connect idea with result.
That's why it is so common to hear something like: "The body is done in Rhino.
The texture is done in POVray. The wheels are also done intirly in POVray." POV
can be used in scenes in many ways: as modeller, as raytracer, as texturing
tool, to create image_maps for other scenes. And as all in one.

> I'm too unpatient for that 
> and bevor I waste my time to learn the SDL en detail to make some balls or 
> cones I rather use Blender. :)

You have to understand that everything what modeller do is just some interactive
action to get input for algorithm performed over primitive objects and textures
to make some complexity which looks soft, organic etc. And as such this action
can be recreated in scripting language with necessary programing capabilities
and set of 3D functions to create primitives. The difference is that in modeller
everything is 'on-screen' in windows while in SDL everything is 'in-manual' and
'in-brain' ;-)

The most important thing which limits possibilities of POV-Ray output is user:
his knowledge, willingness, free time. But these are reality reasons and
therefore some users use modellers and some use pure SDL. And sometimes they
even cooperate exchenging content in some portable format like SDL or OBJ. And
some postprocess their work either as 3D data (in SDL or in modeller) or 2D
image output (in SDL or in image manipulation format).

ABX

Post a reply to this message

Peter Popov wrote:

> AutoCAD is still better for drawing and sketching, though, but of
> course that's what it was intended to do in the first place. That's
> why I always model in Rhino and export to AutoCAD for the engineering
> drawing when I make some design (like my current loudspeaker-to-be).

C'mon Peter! If you have a couple of thousand hours to torture yourself,
Autocad can produce great 3D objects. Look what I accomplished with it 5
years ago -

http://jkuag.tripod.com/gallery/trumpet.jpg

:~)

-- 
Ken Tyler

Post a reply to this message

On Fri, 18 Apr 2003 12:09:00 +0200, ABX <abx### [at] abxartpl> wrote:
> On Fri, 18 Apr 2003 01:04:12 +0200, Andreas Kreisig <and### [at] gmxde> wrote:
> > A view examples: with a lot of patience you can make something like a car, 
> > but you're not able to make a Porsche 911 or a VW Golf or whatever.
>
> http://news.povray.org/povray.binaries.images/19709/127888/MyCar.jpg
> http://news.povray.org/povray.binaries.images/30145/214068/recar3dc5.jpg
> http://news.povray.org/povray.binaries.images/22626/156738/susp.jpg
> http://news.povray.org/povray.binaries.images/30945/220060/FORDTRCK.jpg
> http://news.povray.org/povray.binaries.images/31112/221106/WALL.jpg

Oh, I forgot this site :-)

http://www.geocities.com/SoHo/Gallery/7241/Garage/tii_2.jpg
http://www.geocities.com/SoHo/Gallery/7241/Garage/f37_2a.jpg
http://www.geocities.com/SoHo/Gallery/7241/Garage/t_1a.jpg

ABX

Post a reply to this message

ABX wrote:


>> A view examples: with a lot of patience you can make something like a
>> car, but you're not able to make a Porsche 911 or a VW Golf or whatever.
> 
> http://news.povray.org/povray.binaries.images/19709/127888/MyCar.jpg
> http://news.povray.org/povray.binaries.images/30145/214068/recar3dc5.jpg
> http://news.povray.org/povray.binaries.images/22626/156738/susp.jpg
> http://news.povray.org/povray.binaries.images/30945/220060/FORDTRCK.jpg
> http://news.povray.org/povray.binaries.images/31112/221106/WALL.jpg

That's exactly what I mean: this images shows something like a car, but no 
really car. When I write cars I mean something like this:

http://www.kk.iij4u.or.jp/~knight/images/gallery_image/enzo_re.jpg
http://www.ays-arts.de/gallery/lw7/mz6-01.jpg
http://www.simonreeves.co.uk/3d/rs6/rs6front.jpg

> As Ingo pointed out POV is just one of tools used to connect idea with
> result. That's why it is so common to hear something like: "The body is
> done in Rhino. The texture is done in POVray. The wheels are also done
> intirly in POVray." POV can be used in scenes in many ways: as modeller,
> as raytracer, as texturing tool, to create image_maps for other scenes.
> And as all in one.

Yes.

> You have to understand that everything what modeller do is just some
> interactive action to get input for algorithm performed over primitive
> objects and textures to make some complexity which looks soft, organic
> etc.

The difference is that a modeller like Maya or XSI don't need algorithms to 
work with primitives. They just store the x|y|z coordinates. BTW: to work 
with primitives (CSG) is somewhat outdated. Nowadays most artists use 
boxmodelling, splinecages or something similar. Impossible or very hard to 
do with POV-Rays SDL. To get smoothed results you have to use NURBS, 
subdivision surfaces, Hypernurbs, weighted vertices or whatever. All this 
needs a modeller when you want to get good results because you need the 
optical feedback.

> And as such this action can be recreated in scripting language with
> necessary programing capabilities and set of 3D functions to create
> primitives. The difference is that in modeller everything is 'on-screen'
> in windows while in SDL everything is 'in-manual' and 'in-brain' ;-)

True but misleading. When I make something more complex in Wings3D (a great 
tool!!) then I have to tweak and fine tune a lot. When you use an algorithm 
based language you don't have enough controll to move one vertex by one. 
And you don't want to tell me that you make an object by using a hand coded 
mesh2?
Here is an example I made with Wings a view month ago:

http://www.render-zone.com/wip/rep_man_prev.jpg

This is not realistic of course but try something like this with SDL. I 
needed 5 hours to build it in Wings - it was just a test to figure out how 
Wings works.
Hey, I don't want to start a flame war here. POV-Ray is a great tool but the 
SDL is limited by its concept not by the user. At least under practical 
circumstances.

Regards,
Andreas

-- 
http://www.render-zone.com

Post a reply to this message

ingo wrote:

Hi Ingo,

> How many hours did it take DAZ to create Vicky? Does she look realistic?

Well, DAZ modells are more or less close to reality. But you will never be 
able to make something similar with POV-Ray!

Andreas

-- 
http://www.render-zone.com

Post a reply to this message

in news:3ea03fdb@news.povray.org Andreas Kreisig wrote:

> To get smoothed results you have to use NURBS, 
> subdivision surfaces, Hypernurbs, weighted vertices or whatever. All
> this needs a modeller when you want to get good results because you
> need the optical feedback.
> 
> [...] And you don't want to tell me that you make an
> object by using a hand coded mesh2?
> 

This is where you undersetimate SDL. There are macros / include files 
available to generate NURBS surfaces, subdivision surfaces etc. Just like 
you don't draw every single triangle of a model by hand using a GUI, you 
don't need to when using SDL.

Ingo

Post a reply to this message

In article <3ea03fdb@news.povray.org> , Andreas Kreisig <and### [at] gmxde> 
wrote:

> BTW: to work
> with primitives (CSG) is somewhat outdated.

No, here you are wrong.  It simply happens that CSG is harder to do if you
don't use plain ray-tracing.  And the default renderers shipped with any
commercial package today do not use plain ray-tracing, but various hybrid
scanline/ray-tracing methods.  And those methods cannot easily do CSG, but
they need to precompute what they call CSG in the modeler interfaces...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Fri, 18 Apr 2003 20:17:55 +0200, Andreas Kreisig <and### [at] gmxde> wrote:
> > http://news.povray.org/povray.binaries.images/19709/127888/MyCar.jpg
> > http://news.povray.org/povray.binaries.images/30145/214068/recar3dc5.jpg
> > http://news.povray.org/povray.binaries.images/22626/156738/susp.jpg
> > http://news.povray.org/povray.binaries.images/30945/220060/FORDTRCK.jpg
> > http://news.povray.org/povray.binaries.images/31112/221106/WALL.jpg
>
> That's exactly what I mean: this images shows something like a car, but no 
> really car.

Is that becouse they have no name ?

> When I write cars I mean something like this:
>
> http://www.kk.iij4u.or.jp/~knight/images/gallery_image/enzo_re.jpg
> http://www.ays-arts.de/gallery/lw7/mz6-01.jpg
> http://www.simonreeves.co.uk/3d/rs6/rs6front.jpg

You mean level of details ? Background ? Making exactly along sheet of plans ?
In what way those cars are better then those from my links ? And why Nekar has
won with his model?

> > You have to understand that everything what modeller do is just some
> > interactive action to get input for algorithm performed over primitive
> > objects and textures to make some complexity which looks soft, organic
> > etc.
>
> The difference is that a modeller like Maya or XSI don't need algorithms to 
> work with primitives.

They usually need triangles. Triangle is one of primitives, isn't it?

> They just store the x|y|z coordinates. BTW: to work 
> with primitives (CSG) is somewhat outdated. Nowadays most artists use 
> boxmodelling, splinecages or something similar.

And some use POV. Please do not compare images from povray.binaries.images with
works of artists working with other packages. Please compare POV artists with
artists in other packages. Please compare scientist working with POV and
scientist working with other packages.

> Impossible or very hard to 
> do with POV-Rays SDL. To get smoothed results you have to use NURBS, 
> subdivision surfaces, Hypernurbs, weighted vertices or whatever. All this 
> needs a modeller when you want to get good results because you need the 
> optical feedback.

Yes and no. Nobody is saying POV is for every work.

> > And as such this action can be recreated in scripting language with
> > necessary programing capabilities and set of 3D functions to create
> > primitives. The difference is that in modeller everything is 'on-screen'
> > in windows while in SDL everything is 'in-manual' and 'in-brain' ;-)
>
> True but misleading. When I make something more complex in Wings3D (a great 
> tool!!) then I have to tweak and fine tune a lot. When you use an algorithm 
> based language you don't have enough controll to move one vertex by one. 

Yes. Because you develope algorithm to work the way you want. If algorithm is
good you do not need to move one vertex. If algorithm is not best you can
"postprocess" otput outputing data and introducing some noise with just one
loop. And I do not say POV is better than modelers here. Some users work one
way. Some users work another way. Some minds are oriented on view and some are
oriented on concept, coordinates, paths and properities expressed with values.
For some pixel resolution is the truth. For some it is floating point accuracy.

> And you don't want to tell me that you make an object by using a hand coded 
> mesh2?

That's because you seem think trangle-oriented modelling is the only way.
CSG is another:
http://news.povray.org/search/advanced/?s=Rasmussen&g=povray.binaries.images&a=1
Isosurface is another:
http://news.povray.org/povray.binaries.images/13780/
http://news.povray.org/povray.binaries.images/13083/
Blob is another. Media is another.

> This is not realistic of course but try something like this with SDL. I 
> needed 5 hours to build it in Wings - it was just a test to figure out how 
> Wings works.

Great! You made head in one tool. Now you can use another tool to make another
element of scene. In other words. You have head. Put a tree in perspective. Nice
unique tree. With enough resolution for high quality image (8000x6000). With
great SDL macros written by somebody it takes seconds. And you can modify it to
go outside of some area (head?). Can you be faster with modeller ?

> Hey, I don't want to start a flame war here. POV-Ray is a great tool but the 
> SDL is limited by its concept not by the user. At least under practical 
> circumstances.

No. Under lazyness and unpatience of user ;-)

ABX

Post a reply to this message

On Fri, 18 Apr 2003 20:17:55 +0200, Andreas Kreisig <and### [at] gmxde> wrote:
> Nowadays most artists

BTW: How nowadays artists solve distributed workgroup cooperation?

ABX

Post a reply to this message

ingo wrote:
> How many hours did it take DAZ to create Vicky? Does she look realistic?

Vicky was not built by hand.  Vicky was made using a 3d-scanner.
Hideously expensive to own, not exactly cheap to rent use of one
either, but that's how they build human meshes that look realistic.

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Andreas Kreisig wrote:
> 
> [...]
> 
> The difference is that a modeller like Maya or XSI don't need algorithms to
> work with primitives. They just store the x|y|z coordinates. BTW: to work
> with primitives (CSG) is somewhat outdated. Nowadays most artists use
> boxmodelling, splinecages or something similar. 

Hah!

Don't believe all the stuff the marketing guys from the CG industry are
trying to tell you.  They are trying to sell their software and if it
can't handle anything but triangles because it works with scanline
rendering techniques triangles are of course presented as the only way to
represent geometries efficiently.  Apart from that you will have a hard
time creating a nice tree or anything similarly detailed by hand.  It's
just the contrary of being outdated - with increasing computation power
algorithmically generated geometry will become more and more important
because the time necessary to model complex things by hand will no more be
affordable.

As an example - you will hardly find a detailed tree or terrain model that
is created manually.  On the other hand both can be created with POV-SDL
very efficiently.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Yes, SDL is limited as there are many things (mostly women and cars) 
which are really difficult to describe in it and you cant get imidiate 
visual feedback but modelers are as limited as there are also many 
things (the grass and the trees) which are best described algorithmically.

I think the best you can do is to combine the two approaches, you 
wouldn't want to model a forest but deciding what it will look like by 
painting some maps to controll some paramenters adding some noise and 
then have a cool forest which although its random is inside the 
parameters you wanted it to be is really powerfull.

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3ea03fdb@news.povray.org> , Andreas Kreisig <and### [at] gmxde> 
> wrote:
> 
> 
>>BTW: to work
>>with primitives (CSG) is somewhat outdated.
> 
> 
> No, here you are wrong.  It simply happens that CSG is harder to do if you
> don't use plain ray-tracing.  

I think even if people used plain raytracing, they wouldn't use CSG as 
their primary modelling method.

>And the default renderers shipped with any
> commercial package today do not use plain ray-tracing, but various hybrid
> scanline/ray-tracing methods.  

Are you sure? Cinema4d seems to do raytracing and when I last saw it you 
could do "zu Grundobjekt konvertieren" when you were doing CSG with 
primitives.

Post a reply to this message

in news:3ea05673@news.povray.org Timothy R. Cook wrote:

>> How many hours did it take DAZ to create Vicky? Does she look
>> realistic? 
> 
> Vicky was not built by hand.

I knew that ;)


Ingo

Post a reply to this message

in news:3EA06029.C923BFC9@gmx.de Christoph Hormann wrote:

> with increasing computation power
> algorithmically generated geometry will become more and more
> important because the time necessary to model complex things by hand
> will no more be affordable.
> 

And in the future POV-Ray will have a groundbreaking DNA{} object. You 
yust add the right DNA-sequence to it and the model will be build.

Ingo

Post a reply to this message

In article <3ea07c18$1@news.povray.org> , Simon Adameit 
<sim### [at] gaussschule-bsde>  wrote:

> Are you sure? Cinema4d seems to do raytracing

Yes, it is the closest you can get to plain ray-tracing.  Still, it is
hybrid method as it relies at least on various light and reflection tricks;
at least that is what the images suggest when looking closely at light,
shadow and reflection compared to knwon ray-traced images.  I actually
downloaded to manual (the whole 42 MB), but it does not say anything about
technical issues at all :-(

> and when I last saw it you
> could do "zu Grundobjekt konvertieren" when you were doing CSG with
> primitives.

That sure sounds like it could have something to do with primitives, but it
is very hard to tell without actually seeing their code...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Timothy R. Cook wrote:
> ingo wrote:
> > How many hours did it take DAZ to create Vicky? Does she look realistic?
>
> Vicky was not built by hand.  Vicky was made using a 3d-scanner.
> Hideously expensive to own, not exactly cheap to rent use of one
> either, but that's how they build human meshes that look realistic.

Well, AFAIK the models created by 3d-scanner are only used as a reference to
digitally sculpt a lower resolution mesh that will animate more smoothly or
then the scanned model is used to get a displacement map for a low res cage.
There are also lots of people who make realistic human models 'by hand'.
Steven Stahlberg and Peter Syomka are on the top 10 of my list. It's
actually not even too complicated when you have an app that you can work
with and you know anatomy sufficiently.

--
-Jide

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3ea07c18$1@news.povray.org> , Simon Adameit 
> <sim### [at] gaussschule-bsde>  wrote:
> 
> 
>>Are you sure? Cinema4d seems to do raytracing
> 
> 
> Yes, it is the closest you can get to plain ray-tracing.  Still, it is
> hybrid method as it relies at least on various light and reflection tricks;
> at least that is what the images suggest when looking closely at light,
> shadow and reflection compared to knwon ray-traced images.  

A friend of mine has it and you have the option of choosing between hard 
shadows, shadow map and area light. Might be that the images you mean 
were rendered with shadow maps though I dont know what could be the 
reflection trick.

>I actually
> downloaded to manual (the whole 42 MB), but it does not say anything about
> technical issues at all :-(

Perhaps their c++ sdk doc can tell you more:
http://www.plugincafe.com/r8sdk/index.html

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> I actually
> downloaded to manual (the whole 42 MB), but it does not say anything about
> technical issues at all :-(

  I think that's one difference between "professional" commercial renderers
and amateur free ones. :)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3ea14dcc@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> I actually
>> downloaded to manual (the whole 42 MB), but it does not say anything about
>> technical issues at all :-(
>
>   I think that's one difference between "professional" commercial renderers
> and amateur free ones. :)

No, the manual was included in German and English, and there where plenty of
example movies (or something like that, I didn't watch them).  So they are
just better cheating ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <3ea14dcc@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
> 
> >> I actually
> >> downloaded to manual (the whole 42 MB), but it does not say anything about
> >> technical issues at all :-(
> >
> >   I think that's one difference between "professional" commercial renderers
> > and amateur free ones. :)
> 
> No, the manual was included in German and English, and there where plenty of
> example movies (or something like that, I didn't watch them).  So they are
> just better cheating ;-)

Actually I think Warp was referring to the fact that the documentation from a
commercial rendering package never discusses the technology behind how it works
whereas POV-Ray (an amateur free program) does an excellent job of it.

-- 
Ken Tyler

Post a reply to this message

In article <3ea07c18$1@news.povray.org>,
 Simon Adameit <sim### [at] gaussschule-bsde> wrote:

> > No, here you are wrong.  It simply happens that CSG is harder to do if you
> > don't use plain ray-tracing.  
> 
> I think even if people used plain raytracing, they wouldn't use CSG as 
> their primary modelling method.

Most modellers use polygon representations to provide a real-time 
preview of the scene, and faster but lower quality scanline rendering, 
so of course when they raytrace they use the same data. Primitive CSG is 
generally faster and uses less memory, but it requires primitives that 
are harder to preview and scanline render, you generally have to 
tesselate them first. If they used pure raytracing, they would use CSG 
of primitives unless meshes were absolutely necessary, it would be the 
most efficient way to do the job.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> In article <3ea07c18$1@news.povray.org>,
>  Simon Adameit <sim### [at] gaussschule-bsde> wrote:
> 
> 
>>>No, here you are wrong.  It simply happens that CSG is harder to do if you
>>>don't use plain ray-tracing.  
>>
>>I think even if people used plain raytracing, they wouldn't use CSG as 
>>their primary modelling method.
> 
> 
> Most modellers use polygon representations to provide a real-time 
> preview of the scene, and faster but lower quality scanline rendering, 
> so of course when they raytrace they use the same data. Primitive CSG is 
> generally faster and uses less memory, but it requires primitives that 
> are harder to preview and scanline render, you generally have to 
> tesselate them first. If they used pure raytracing, they would use CSG 
> of primitives unless meshes were absolutely necessary, it would be the 
> most efficient way to do the job.
> 

Its just that most of the time meshes are absolutely necessary. 
Primitive CSG is to limited in what kind of objects you can create so it 
would be used but probably not much. I think the reason why CSG is used 
so much in POV is that its easy to create objects this way using the 
SDL. And pure raytracing doesn't mean that you are not able to model and 
preview in real-time.

Post a reply to this message

In article <3ea19c47@news.povray.org> , Simon Adameit 
<sim### [at] gaussschule-bsde>  wrote:

> And pure raytracing doesn't mean that you are not able to model and
> preview in real-time.

Well, if the preview excludes everything (most importantly the recursive
part of the process) that makes ray-tracing what it is, sure, but then you
can just as well use other approaches which will actually produce better
results more quickly for everything but the most complex scenes.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3ea19c47@news.povray.org> , Simon Adameit 
> <sim### [at] gaussschule-bsde>  wrote:
> 
> 
>>And pure raytracing doesn't mean that you are not able to model and
>>preview in real-time.
> 
> 
> Well, if the preview excludes everything (most importantly the recursive
> part of the process) that makes ray-tracing what it is, sure, but then you
> can just as well use other approaches which will actually produce better
> results more quickly for everything but the most complex scenes.
> 

but is it still pure raytracing ;-)

regarding your last comment, how compares raytracing with other 
techniques when complexity grows?

Post a reply to this message

In article <3ea1d418$1@news.povray.org> , Simon Adameit 
<sim### [at] gaussschule-bsde>  wrote:

> regarding your last comment, how compares raytracing with other
> techniques when complexity grows?

In short:

With scanline rendering you have to draw every object potentially
intersecting the view frustum in order to determine its visibility.  That
is, the bounding volumes a scene contains are only good for determining
whether objects (actually, their bounding volumes) intersect the view
frustum.  Then you have to transform them and draw those objects.  As
objects can only consist of polygons, you have to transform all those points
(or build the mesh on the fly, which is even more work).  And then start
drawing the triangles.  And it may turn out that only a tiny little fraction
of those triangles is really visible.  Many points drawn will in fact be
hidden behind others the more objects are in the scene.

With ray-tracing you can use bounding everywhere. Once you have identified
the object with the closest bounding volume, you calculate the intersection.
If there is non, pick the object with the second closest bounding volume
(which you already have as you found it while searching for the closest one)
and so on. And there are a lot of ways to easily determine which bounding
volumes are closest.  Certain algorithms allow storage of bounding
information such that you will have an almost sorted list of only the
bounding volumes within the view frustum.  Or you use other data structures
to represent the scene.

So, you end up with something like this for scanline rendering:

Lets assume you have a scene with 50 million triangles within the view
frustum at one frame (which is about as many triangles as scanline rendering
hardware can draw per second today - and I am talking about realistic
numbers, not the theoretical maximum marketing people list somewhere).

Lets further assume we have a screen with about one megapixel, that is i.e.
1152*870 pixels (a format not too common today, but then years ago it was).

So, now there are on average 50 triangles which contribute to one pixel. In
fact, assuming an average size of 10 pixels, there are 500 triangle pixels
per pixel, but lets ignore this number here now - the 50 triangles are
already bad enough.  So, for every pixel you will have to perform at least
one transformation (assuming every triangle has two points in common with
other triangles - this isn't the case, they will have less than two in
common on average), which is a matrix multiplication plus a transformation
into screen coordinates (to get your triangles from 3D to 2D).

Lets assume to perform this computation takes 20 nanoseconds (ns), which is
realistic on hardware today.  So, 50 * 20 ns = 1000 ns for the 50 triangles
(and thus for 50 million triangles one second).

And for ray-tracing, using only simple algorithms, without (!!!) advanced
algorithms that do better than plain bounding volumes, you get:

Assume that the 50 million triangles belong to 1000 objects with 50000
triangles each.  So we end up with 1000 bounding volumes, which will take no
more than 1000 * lg 1000 = (about) 10000 steps to sort by distance from the
viewpoint.  Lets assume every step takes 10 ns (probably it takes less).  So
it takes 100000 ns to do.  Lets also ignore that it took another 100 ns or
so to determine the distance of each viewing volume from the viewpoint.
Thus, this takes 1/5000 of a second, and we will ignore this for now because
the really important computation follows.

Compute the intersection of a ray with the bounding volume.  Lets assume for
simplicity that this volume is a sphere, and the intersection test takes 20
ns on average (which is fairly realistic).  But how many will we have to
compute on average?  This is the really important point, and it depends on
the size of the objects.  Remember we assumed before that every triangle
consists of about 10 visible pixels?  Lets now also assume that objects have
a volume, that is, they have two sides, so we end up with about 50000
triangles per object * 10 pixels per triangle = 500000 pixels per objects,
and half are not facing us, thus 250000 pixels is the average size of the
objects.  This yields about 250 objects per pixel.  Thus, it takes about
four intersection tests with bounding volumes to find the first one that is
intersecting (less actually, as bounding volumes won't be optimal).  Lets
assume we always miss the first object, thus there will be on average 20 ns
* 8 = 160 ns intersection tests with bounding volumes.  Which leaves up
about 840 ns to finding the actual intersection with one of the 50000
triangles.  This is possible because the triangles are again separated in
several bounding volumes.  I am not going to go into detail here, but you
can find many algorithms on the internet.  Lets assume the bounding
hierarchy splits the space in even boxes, 16 * 16 * 16 boxes (4096), this
yields on average 12 triangles per box and we can walk them following a 3D
line (which costs us essentially nothing).  Lets assume an intersection test
takes 30 ns on average (triangle intersection is a bit more complex, but
allows early bailout if no intersection can occur), we can do 840 ns/ 30 ns
= 28 intersection tests per pixel.

In conclusion, just taking the transformations, any ignoring the fact that
the scanline rendered will have to test 500 million pixels whether they are
visible or not by performing a comparison with the z-buffer, ray-tracing
will be faster finding the intersection already, without still having to
perform those 500 million comparisons, which take 1/5 of second for sure,
and generate 1.9 GB memory traffic, plus another 1.9 GB for storing the
pixels and overwriting them when a closer one was found.  Plus the 0.8 GB it
takes to read the triangles.  Which gives a total of 4.6 GB.  Texturing and
so on isn't even included.

For the plain drawing ray-tracing will only generate 4 MB of memory traffic.
The bounding volume tests will be require 8 spheres * 16 bytes (position
plus radius of the sphere) per pixel, plus 28 triangles * 36 bytes (three
points) yield only 1.6 GB of memory traffic, roughly one third the scanline
renderer needed.

So, as you can see (if you managed to read on to here), if the scene
complexity rises, ray-tracing gets more economical, even for things like
triangle meshes.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3ea1d418$1@news.povray.org> , Simon Adameit 
> <sim### [at] gaussschule-bsde>  wrote:
> 
> 
>>regarding your last comment, how compares raytracing with other
>>techniques when complexity grows?
> 
> 
> In short:
> 

Thanks for you detailed explanation.

> So, as you can see (if you managed to read on to here), if the scene
> complexity rises, ray-tracing gets more economical, even for things like
> triangle meshes.
> 

Unfortunately complexity is limited by memory.

Post a reply to this message

Simon Adameit wrote:

> Thorsten Froehlich wrote:
>> In article <3ea1d418$1@news.povray.org> , Simon Adameit
>> <sim### [at] gaussschule-bsde>  wrote:
>> 
>> 
>>>regarding your last comment, how compares raytracing with other
>>>techniques when complexity grows?
>> 
>> 
>> In short:
>> 
> 
> Thanks for you detailed explanation.
> 
>> So, as you can see (if you managed to read on to here), if the scene
>> complexity rises, ray-tracing gets more economical, even for things like
>> triangle meshes.
>> 
> 
> Unfortunately complexity is limited by memory.

I'm not familiar with rendering algorithms, but aren't there any rendering 
systems available(e.g. Pixar's Renderman wich is a hybrid renderer) wich 
are able to pipe the input so that the memory is not the limited factor?

Andreas

-- 
http://www.render-zone.com

Post a reply to this message

Andreas Kreisig wrote:
> 
> I'm not familiar with rendering algorithms, but aren't there any rendering 
> systems available(e.g. Pixar's Renderman wich is a hybrid renderer) wich 
> are able to pipe the input so that the memory is not the limited factor?
> 
> Andreas
> 

Pixar's Renderman uses the reyes algorithm. Afaik its much like 
scanlining but divides the objects into a grid of sub-pixel 
micropolygons which makes detailed displacement mapping possible.
But due to its nature it cannot render realistic shadows, reflections 
and refractions.

There are also some approaches to memoy coherent raytracing (normal 
raytracing always requires access to any part of the scene) but from 
what I know they only work when you dont have complex lightning like 
radiosity or hundrets of light sources.

But complexity in raytracing can also be achieved with other rhings than 
meshes like isosurfaces for detailed landscapes.

Post a reply to this message

In article <3ea29431@news.povray.org> , Andreas Kreisig <and### [at] gmxde> 
wrote:

> I'm not familiar with rendering algorithms, but aren't there any rendering
> systems available(e.g. Pixar's Renderman wich is a hybrid renderer) wich
> are able to pipe the input so that the memory is not the limited factor?

Of course you can always parallelize either process, random memory access
does not scale well at all.  Memory access is the limit even for
ray-tracing, and for scanline rendering hardware the memory access is the
reason why memory hardware is much faster than main system memory.  But
there are limits to the memory speed, which are physical and somewhere
around 50-100 times of what is possible today (because the signal can't
travel faster than light).  So those absolute limits will be reached really
soon for classic integrated circuits; and already the high-frequency
characteristics of memory bus signals cause a lot of problems...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3ea29335@news.povray.org> , Simon Adameit 
<sim### [at] gaussschule-bsde>  wrote:

>> In short:
>
> Thanks for you detailed explanation.

Actually, I was serious that this was the short version.  In reality the
whole issue is even more complicated, and very hard to describe, let alone
predict exactly :-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3ea2a059@news.povray.org> , Simon Adameit 
<sim### [at] gaussschule-bsde>  wrote:

> But complexity in raytracing can also be achieved with other rhings than
> meshes like isosurfaces for detailed landscapes.

Actually, landscapes are one of the few things for which extremely efficient
algorithms exist that are very good at limiting complexity using dynamic
level of detail methods.  Much of these where invented because the military
needed flight simulators* that where realistic long before hardware could
solve the problem without clever algorithms...

    Thorsten

* Realism was reached by the mid-1980s, or at least that was when it was
presented on SIGGRAPH for the first time.

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Simon Adameit wrote:

> Pixar's Renderman uses the reyes algorithm. Afaik its much like
> scanlining but divides the objects into a grid of sub-pixel
> micropolygons which makes detailed displacement mapping possible.
> But due to its nature it cannot render realistic shadows, reflections
> and refractions.

As far as I know the latest PRman release can do both: reyes based rendering 
and reytracing. It uses selective raytracing wich will only be enabled when 
it is needed.

Andreas
-- 
http://www.render-zone.com

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3ea29431@news.povray.org> , Andreas Kreisig <and### [at] gmxde>
> wrote:
> 
>> I'm not familiar with rendering algorithms, but aren't there any
>> rendering systems available(e.g. Pixar's Renderman wich is a hybrid
>> renderer) wich are able to pipe the input so that the memory is not the
>> limited factor?
> 
> Of course you can always parallelize either process, random memory access
> does not scale well at all.  Memory access is the limit even for
> ray-tracing, and for scanline rendering hardware the memory access is the
> reason why memory hardware is much faster than main system memory.

Well, I mean render engines wich don't have to parse the hole scene. It can 
do it in parts and when one part is rendered it will leave the pipe (and so 
it will free the memory). Don't know how they realize this but I read an 
article about that and they rendered test scenes with an astronomic number 
of verts or triangels.

Andreas

-- 
http://www.render-zone.com

Post a reply to this message

Thorsten Froehlich wrote:
> 
> > But complexity in raytracing can also be achieved with other rhings than
> > meshes like isosurfaces for detailed landscapes.
> 
> Actually, landscapes are one of the few things for which extremely efficient
> algorithms exist that are very good at limiting complexity using dynamic
> level of detail methods.  Much of these where invented because the military
> needed flight simulators* that where realistic long before hardware could
> solve the problem without clever algorithms...

Reducing the problem of generating realistic terrain display to the
requirements of 'flight simulator like' applications (meaning low
resolution, large area, possibly realtime display of heightfield data)
does not cover this problem sufficiently.  As i have mentioned elsewhere
in this thread terrain geometry is a very good example for a problem where
procedural geometry can clearly be superior to the classical hand made
mesh approach because terrain geometry is very complex but can be fairly
well described algorithmically.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3ea29335@news.povray.org>, sim### [at] gaussschule-bsde says...
> Thorsten Froehlich wrote:
> > In article <3ea1d418$1@news.povray.org> , Simon Adameit 
> > <sim### [at] gaussschule-bsde>  wrote:
> > 
> > 
> >>regarding your last comment, how compares raytracing with other
> >>techniques when complexity grows?
> > 
> > 
> > In short:
> > 
> 
> Thanks for you detailed explanation.
> 
> > So, as you can see (if you managed to read on to here), if the scene
> > complexity rises, ray-tracing gets more economical, even for things like
> > triangle meshes.
> > 
> 
> Unfortunately complexity is limited by memory.
> 
> 
It should be noted that, with games at least, some rendering engines 
combine features of scanline and raytrace. In general, the difference is 
often accuracy and effects. A triangle based sphere needs to somehow gain 
triangles the closer you get to it, so will never be as accurate as a 
raytraced one. Obvious of course, but the same issue exists with 'any' 
mesh you use. The other factor is that you either use the hardware 
acceleration, or calc nearly everything in your program anyway, since the 
cards can't do complex things like refraction, reflection, etc. They just 
slap triangles in the screen and slap a texture over them. Some older 
cards couldn't even do this right. lol

Due to this a lot of games speed things up when they have huge meshes by 
z-buffering them internally into planes. In other words, they chop up the 
existing meshes into layers that will get sent to the card, use something 
like a raytracers bounding to eliminate any triangles that you won't see 
and then dump the rest to the card, or lacking a card, through a scanline 
system that just draws everything and maps a texture to it (which is more 
or less what Doom did). Or if games don't do this, then it is quite 
silly, since even if the cards themselves perform something similar, 
there is as you say a distinct limit to how much junk you can hand even 
the best OpenGL or DirectX card before you run out of memory, especially 
since you also have to dump huge textures to the card as well. On a 
modern machine you could very nearly produce a frame rate as good as or 
better than any 3D card by using pure raytrace and procedural textures, 
where you only used meshes when needed, and even that isn't a 'major' 
slow down.

The only real issue is structuring the data in a way that lets you load 
it fast. Some level of persistence of objects from frame to frame, so you 
only parsed 'new' objects or transitional information would pretty 
well vaporize that issue. Considering how high-poly action scenes in 
stuff like the XBox's Yu-Gi-Oh: War of the Roses game load so insanely 
slow from what I hear that people turn them off, even the existing parse 
time for each frame of the same scene using POVRay would probably take 
less time to 'load' the animation frames needed by generating them each 
frame individually. ;) I would say that no matter how much they improve 
the cards themselves, the main issue is now becoming how to get the 
bloody data to them in the first place and the way they work actually 
makes that significantly harder to do, no matter what the frame rate per 
poly-count now is. ;) lol

But that gets slightly off topic. ;) Knowing how poly-based systems work, 
I suspect that the in-program views use scanline, but any such tool that 
claims to be able to export the result will use more conventional 
raytracing to produce a final result. A few even say something to that 
effect in some obscure corner of the docs, but since the main problem is 
almost always the obvious mesh nature of its objects when seen too 
closely, or just plain at the wrong angle....

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message