 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Actually MegaPOV 1.0 for DOS fits perfectly on one 1,44 floppy :-)
>http://megapov.inetart.net/download.html
Ouch. I give up, MegaPov was great and a welcome addition
at the time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Willem wrote:
>
> > I cannot even imagine how much it took to program this into
> > a raytracer (a great job !!),
> I mean this, a complement well deserved.
I read this but to be frank - how can you know it is a great job if you
did not actually use it.
> These should not be part of a renderer which should just render any
> datafile whe feed it.
I am not going to discuss the decision to integrate mechsim into POV-Ray.
If you don't understand the extremely obvious reasons for this you should
probably either use POV-Ray more intensively or have a look at the
mechsim source.
I don't want to sound selfish so again, if you prefer to use a different
tool i am the last one preventing you from doing so but your arguments are
rather weak.
> Could we compare ? i.e. create a sample scene, a sort of a skyvase
> for mechsim and compare on speed an accuracy ? See where the limits
> are ?
That's a great idea - just take one of the sample scenes. 'bar.pov' and
'tshirt.pov' are good test cases for this. The 'tutorial06.pov' scene
from the tutorial would be worth trying too. Good luck!
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I only see 473 kb of this:
M/^]/^]/^\11S_O3_O3_O3_O$4<_[T_[T_[T_[Q%!#/^_7S^;Q_%T_[]?/YO'
M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
M_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7
MS^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'
M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
if you use Outlook express, highlight both messages, and right click select
combine and decode, you will get both attachments
Kruger
"Apache" <apa### [at] yahoo com> wrote in message
news:3e47de05@news.povray.org...
> I only see 473 kb of this:
> M/^]/^]/^\11S_O3_O3_O3_O$4<_[T_[T_[T_[Q%!#/^_7S^;Q_%T_[]?/YO'
> M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
> M_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7
> MS^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'
> M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I am not going to discuss the decision to integrate mechsim into POV-Ray.
>If you don't understand the extremely obvious reasons for this you should
>probably either use POV-Ray more intensively or have a look at the
>mechsim source.
Hmm, I have looked at the Mechsim source, but that is not where the
answer is. The answer is in the architecture of the software we use.
Look for instance at the Pixar & ILM world where modelling &
animation is separated from the rendering. This have two advantages,
you can concentrate on the modelling using low(er) quality real-time
output i.e OpenGL and later achieve maximum quality output by batch
rendering the output of the modeller.
With POV the solution has always been to incorporate all features into
one single appl. I am still interested to know why you decided to
incorporate simulation features into the POV code base as opposed to
writing a separate modeller. I can think of one big advantage which
pleads for incorporation; objects can interact with almost all other
obejcts within POV, whereas with an external modeller they usually
interact only with blocks, ball and planes :(
What happens if somebody invents a beter and faster
rendering/raytracer algorithm ? All our modelling and simulation
tools, hardcoded into povray become worthless ? It feels like a
marriage without the possibility if divorce.
>I don't want to sound selfish so again, if you prefer to use a different
>tool i am the last one preventing you from doing so but your arguments are
>rather weak.
>
>> Could we compare ? i.e. create a sample scene, a sort of a skyvase
>> for mechsim and compare on speed an accuracy ? See where the limits
>> are ?
>
>That's a great idea - just take one of the sample scenes. 'bar.pov' and
>'tshirt.pov' are good test cases for this. The 'tutorial06.pov' scene
>from the tutorial would be worth trying too. Good luck!
Nice examples. I rendered them already and they are indeed very
interesting. Look for instance at the "chair" example. A object falls
down, land on a "chair" bends and flexes and is later shoved off.
The object is stiff enough to holds it shape, but flexible enough to
bend, yet when pushed sideways it show no friction effects. The same
with the "snake" like behaviour from the other object which slides
over a block.
The objects behave like they are made from rubber, rubbed with a lot
of oil. Flexible, reacting on impact, full recovery afterwards (no
deformation) and able to slide over sharp edges without showing
friction effects or little shocks in movements. So they do not appear
"normal" to me. I like the images and animations though, and I found
the series of dominos falling like wet pieces of cake very amusing but
I am unsure whether whe are really simulating natural behaviour ..
As for the challenge of comparison, it would be very hard to model
this behaviuor in another tool, I could try maybe with a series of
boxes connected with lots of springs and dampers, to create a
harmonica effect. But somehow I've got the feeling you have tried this
already and know the answer :)
Happy coding
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry for this behaviuor from the times the internet was slow
and postings had to be small in order to reach the newsservers.
Most newsreaders can "join sections"
I'll do a repost if want me to.
W
On Mon, 10 Feb 2003 18:14:44 +0100, "Apache"
<apa### [at] yahoocom> wrote:
>I only see 473 kb of this:
>M/^]/^]/^\11S_O3_O3_O3_O$4<_[T_[T_[T_[Q%!#/^_7S^;Q_%T_[]?/YO'
>M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
>M_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7
>MS^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'
>M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 11 Feb 2003 12:22:36 +0100, Willem
<willem_dot_de_dot_wilde_at_xs4all.nl> wrote:
> Hmm, I have looked at the Mechsim source, but that is not where the
> answer is.
There can be. While I'm not the author of mechsim I can guess a lot of
advantages just from one source becouse there is only _one_ file. Have you
seen parser written in mechsim code? Have you seen io stuff written there?
Separated engine for functions to describe environment dependicies? Everything
this is builded in POV-Ray. If you want to concern of algorithm there is no
need to write whole application with parser, image types support, expression
evaluator etc. Being alone coder and heving POV-Ray sources available is
veeeery comfortable situation. And future users will be comfortable becouse
they use new feature without learning whole new scene description language,
knowing adventages and limitations of other features used around simulation
etc.
> The answer is in the architecture of the software we use.
> Look for instance at the Pixar & ILM world where modelling &
> animation is separated from the rendering.
Look for instance at Moray & POV-Ray where modelling & animation is separated
from the rendering. IIRC there was a plugin for 3ds to support POV-Ray.
Addition of Mechsim does not limits external modellers usages. Not talking
that writing something for POV-Ray makes it available at once for whole
variety of all supported platforms.
> This have two advantages,
> you can concentrate on the modelling using low(er) quality real-time
> output i.e OpenGL and later achieve maximum quality output by batch
> rendering the output of the modeller.
see Moray.
> With POV the solution has always been to incorporate all features into
> one single appl.
That's exactly opposite. You have to incorporate only necessary features
becouse whole application background is already written and supported
separately by community.
> I can think of one big advantage which
> pleads for incorporation; objects can interact with almost all other
> obejcts within POV, whereas with an external modeller they usually
> interact only with blocks, ball and planes :(
Also. Using mechsim applied to POV-Ray core you can use the same "tools" to
describe geometry and dependiscies, flow and texturing.
> What happens if somebody invents a beter and faster
> rendering/raytracer algorithm ?
I hope he will share it :-)
> All our modelling and simulation
> tools, hardcoded into povray become worthless ?
Once something is published it is no more worthless :-)
> It feels like a
> marriage without the possibility if divorce.
No. You can apply as many mechanical simulations into POV-Ray as you wish. As
long as it does not use the same keyword for block it can cooperate. Moreover
I can imagine animation where two objects are holded by different engines. You
can even mix mechsim-driven object with objects imported from external
sources.
I suggest to continue discussion at povray.unofficial.patches group.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> animation is separated from the rendering. This have two
> advantages, you can concentrate on the modelling using
> low(er) quality real-time output i.e OpenGL and later
> achieve maximum quality output by batch rendering the
> output of the modeller.
This is a matter of coding the POV script to deal with 2 situations: A final
render, and test render.. I've begun to do this.. This means that I build
the world so that I can switch between the two modes, with one global
boolean variable.. It doesn't mean that I code 2 variants of every object,
but that I switch off the most cpu intensive tasks, until I want a the final
rendering.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I suggest to continue discussion at povray.unofficial.patches group.
Yeah,
No binaries in sight :)
But is fun and educational to discuss these topics
WdW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>This is a matter of coding the POV script to deal with 2 situations: A final
>render, and test render.. I've begun to do this.. This means that I build
>the world so that I can switch between the two modes, with one global
>boolean variable.. It doesn't mean that I code 2 variants of every object,
>but that I switch off the most cpu intensive tasks, until I want a the final
>rendering.
Which leads to question: did you solve the problem or did you
create a work-around ?
I did the same b.t.w.
WdW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
