 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Feb 2003 14:38:44 +0100, Christoph Hormann
<chr### [at] gmx de> 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.
>Feel free to think whatever you want to think but i see no argument in
>your writing that would support this extremely general statement.
Ok, might be too general, see more nuance below
>> You can do these kind of things much faster, more accurate and without
>> the risk of crashing your raytracer with external modellers and
>> simulators.
>
>This strongly indicates that you don't really know what you are talking
>about.
Statements like this will not really engage people in a
discussion..... Plenty of managers in high tech company's pay loads of
money to send their engineers to courses in order to train them not to
make this kind of statements. Trust me on this.
>First of all the mechsim patch is not any more likely to crash
>POV-Ray than any other experimental feature.
True, but I am not comparing with other POV features, I am comparing
with mechanical simulation systems which have, as you know, lots of
mathematical appoximations and in this case "spring & damper" systems
which are inherently unstable when used without extreme caution.
These should not be part of a renderer which should just render any
datafile whe feed it.
>And then i have serious
>doubts that Aero is substantially faster or more accurate simulating the
>same system than the mechsim patch.
From an end-user perspective it certainly was :), it really took
me just a couple of minutes. You give the reason below; I did have the
need the build objects from point masses and to apply the "correct"
stiffness factors. Wooden domino blocks do not bend or deform
when they fall. That is what triggered me in the first place.
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 ?
>What probably makes Aero more appealing to you is the ability to simulate
>the movement of a few basic shapes like boxes and cylinders without the
>necessity to build them from point masses like in mechsim.
Look what it is used for by the other users; they use it for modelling
the behaviour of in-flexible masses, like domino blocks, or balls
falling down a wall filled with obstacles.
Yes I like the simplification approach. Simulation simplified models
correctly gives i.m.h.o. better results than larger, unstable, models.
But maybe recent models and CPU power are catching up on me.
>have a look at the Aero documentation you will recognize that there is a
>serious number of tricks necessary to make this work. This might produce
>reasonable results for falling domino stones but will break into pieces as
>soon as you try a simulation of more complex shapes and deformable bodies.
I know the limitations of aero and the tricks. Deformable bodies are
the holy grail of course. Can you do this ? Can you make a cube which
falls on a corner and actually deforms permanently ?
>BTW animations posted in several pieces will be difficult to view for a
>lot of people.
>Christoph
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> These should not be part of a renderer which should
> just render any datafile whe feed it.
In other words, we could remove half of POV-Ray because it's not very
useful? On the other hand, this is what makes POV-Ray unique.
I predict that in 10 years, Hollywood will use POV-Ray to model and raytrace
everything in their films. The studios will even use it to make coffee.
Moreover, it will replace ICQ and people will communicate through POV-Ray.
The operating system on most computers will be POV based.. well you get the
idea.. ;o) It might be overdriven but POV-Ray is not just a raytracer. It's
already being developed as a programming language, and no experiments are
really useless. It will be interesting to see where the mechsim will go.
But thanks for your input. Of course there will be different opinions, and
we can probably learn something from everyone.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>But thanks for your input. Of course there will be different opinions, and
>we can probably learn something from everyone.
That why they are opinions :)
Just one example: MsWord used to fit on a couple of floppies.....
It has much more functionality now, but is it better ?
Willem
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Feb 2003 16:45:37 +0100, Willem
<willem_dot_de_dot_wilde_at_xs4all.nl> wrote:
> Just one example: MsWord used to fit on a couple of floppies.....
> It has much more functionality now, but is it better ?
Actually MegaPOV 1.0 for DOS fits perfectly on one 1,44 floppy :-)
http://megapov.inetart.net/download.html
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>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] yahoocom> 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
|
|
| |
| |
|
|
|
|
| |
