Hi guys, here's me, Christian.

I promised some days ago to post the content of a RTF file, to try to
explain better an idea I posted on the message titled "About a (maybe) cool
idea with blobs and splines" or something...

I've just declined to post that, because I realiazed that it'd be too comlex
(in the case it'd be possible) to materialize something like that (you were
right, Rune... that was the sigh about, man; don't take it personal), and
my main desire was to colaborate to make things like modelling and
animation more easy, not a LOT more complicated.

Maybe, if I simplifly and order my ideas, that'd be a modeller/animator
project, but with a regular mesh output. But as there're already good
quality free software that already do that (as Anim8or)... it'd be better
to just work on a "connection", right?

I still think that organic movements of objects GOT to be included in POV,
since they're just so beutifoul and cool...

I think it's a lot more factible to just implement internal support for
bones and morph targets, topics wich I'd like to discuss with you sometime
soon.

Well, so... ehm... bad idea (oups!)

Good bye then!

Post a reply to this message

"Christian" <las### [at] hotmailcom> wrote in
news:web.3d8114b21997f3778531b09b0@news.povray.org 

[...]

people here don't like future requests :-/ afaik

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj wrote:

>people here don't like future requests :-/ afaik

Sorry... ehm... what you meant?

Post a reply to this message

"Christian" <las### [at] hotmailcom> wrote in 
news:web.3d8116effeedefd48531b09b0@news.povray.org

>>people here don't like future requests :-/ afaik
> Sorry... ehm... what you meant?

Phong highlight, my env_map, extendet output format (my and someone 
other's), buffering entire output (instead of just 2 lines for AA) and 
meany more - all will NOT be implemented :-/

POV starts imho to look like GL - it's better, faster, free, but it is 
developing to slowly to be widle used.

I have meany good ideas, I may implement them in MY demostration program 
(C++ GCC) but I dont have time (now) to write path. And even if I do - so 
many interesting pathes are not included in official pov. 

What's the probelm to get now all pathes for pov, copy code, do few tests 
and release Pov 3.6 ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <web.3d8114b21997f3778531b09b0@news.povray.org>,
 "Christian" <las### [at] hotmailcom> wrote:

> I still think that organic movements of objects GOT to be included in POV,
> since they're just so beutifoul and cool...

It is just that these things are so complex and, for lack of a better 
word, "sensitive" to parameters, that you really need a real-time GUI 
modeller to get the most benefit. And then the output will be a mesh, or 
you could get differences between how POV calculates things and what the 
modeller intended.


> I think it's a lot more factible to just implement internal support for
> bones and morph targets, topics wich I'd like to discuss with you sometime
> soon.

There have been a couple discussions on these subjects before that may 
be of interest to you, try searching the groups through the web 
interface.

-- 
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

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> people here don't like future requests :-/ afaik

Your feature (not "future") requests may have been unpopular, but that 
was because they were such bad ideas. Ideas for improving POV are always 
welcome.

-- 
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

Yes, I'm getting your point...

It's sad when you see some good examples of cool features (like the one of
that guy who realeased that patched version of POV that made simple cloth
emulation) that are not implemented or further studied... or even
considered...

But maybe that could change, right? Maybe is just a matter or persistence?

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
E04### [at] netplexaussieorg

> In article <Xns### [at] 204213191226>,
>  "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> 
>> people here don't like future requests :-/ afaik
> 
> Your feature (not "future") requests may have been unpopular, but that 
> was because they were such bad ideas. Ideas for improving POV are always 
> welcome.

Wahat is bad in text output of RGB as floats ? They can be loseless 
converted later into CMYK or RGB 48 etc.

Outputing distance can be used in psot-processing in 2-d programs (i.e. 
adding fog).

Distance,<x,y,z> and ID informations make this output files ready-to-use in 
i.e. games (like id 0 - is head, id 1 are robot's legs etc)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> Phong highlight, my env_map, extendet output format (my and someone 
> other's), buffering entire output (instead of just 2 lines for AA) and 
> meany more - all will NOT be implemented :-/

POV has phong highlights. Were you referring to the Gouraud shading 
question? It is a hack of doing lighting calculations on vertices and 
interpolating the color instead of interpolating the normal, is 
something that only applies to scanline renderers, and is mainly useful 
for realtime rendering on older video cards or software. It would take a 
lot of effort to implement in POV, would only be possible for 
tessellated shapes, would give far inferior results, and has no 
advantages.

Environment mapping is a hack designed to simulate reflection for 
systems that can't do real reflection. POV can do real reflection, it 
has no need to use a method that fakes the effect, takes more memory, 
and probably won't give any useful speed increase.

Extended file format? Readable by what? It would take a lot of 
modifications and would only be useful for a few programs designed to 
work with the patch. You should have expected that very few people would 
be interested.

It was explained why your output buffering idea was a bad one. It would 
not speed things up, it would use more memory, and would make you lose 
the entire image if the system crashed or went down for another reason.

There are many other ideas, most of them actually good and useful ones, 
that *were* implemented as patches and incorporated into POV.


> I have meany good ideas, I may implement them in MY demostration program 
> (C++ GCC) but I dont have time (now) to write path. And even if I do - so 
> many interesting pathes are not included in official pov. 

The reason nobody else is interested is that you are the only one who 
think your ideas are good. And your refusal to actually work on POV 
comes across as arrogance. With the quality of your suggestions, I doubt 
you have much skill in programming.


> What's the probelm to get now all pathes for pov, copy code, do few tests 
> and release Pov 3.6 ?

You really have no idea how software is developed, do you? Your previous 
suggestions made it hard to compare, but that has to be the stupidest 
one I have ever seen.

-- 
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

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> Wahat is bad in text output of RGB as floats ? They can be loseless 
> converted later into CMYK or RGB 48 etc.

Nothing bad about it, it is just fairly useless.


> Outputing distance can be used in psot-processing in 2-d programs (i.e. 
> adding fog).
> Distance,<x,y,z> and ID informations make this output files ready-to-use in 
> i.e. games (like id 0 - is head, id 1 are robot's legs etc)

And it has been done, long before you posted anything about it. I wrote 
a patch a very long time ago to output depth information (it was one of 
my first patches), and MegaPOV included a different patch for the 
post-process feature that did the same thing. There were good reasons 
not to add these patches to POV 3.5, they simply weren't ready to be 
added.

-- 
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