"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

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

> Environment mapping is a hack designed to simulate reflection for 

Pointless discusion if You do not want to comment this 3 arguments for 
env_map I gave, AFAIR at least 1 person agree it might be 
usefull/interesting.
 
> Extended file format? Readable by what? 

by
  ifstream f("c:/images/test.txt);
  float r,g,b,id;
  f>>r>>g>>b>>id;
?
Put this in x*y loop, and convert into any format, or use in game as sprite 
with different i.e. hit regions.

> The reason nobody else is interested is that you are the only one who 
> think your ideas are good. 

---- 8< ------------------------------------
I read your article in the povray newsgroup about providing a customized
output file format. The problem you formulated is exactly the problem I
have! And I also browsed the source codes in order to adjust the program.
[...]
P.S. Do you have any other idea of which rendering software to use in order
to obtain (or better: keep) the 3d information which is lost when you get
the 2d output only?
---- 8< ------------------------------------

> And your refusal to actually work on POV  comes across as arrogance. With 
> the quality of your suggestions

No, maybe I didn't put it clear - I do want write code for POV but I know 
that I will have problems with attaching my code to huge code ogf POV and I 
will need help with that.
 
> You really have no idea how software is developed, do you? 

Actualy I do work in software company, but I mostly I develop stand-alone 
programs / modules so I must agree that I don't have practical exeprience 
with putting code written by many persons togeather.

Hmm maybe a little utility .txt -> .bmp that will show possibiliteis of 
that format ?

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