 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] mac com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, Christoph seems to be a little upset, and I hope
we can agree that perhaps the topic itself, "feature
requests", is a little touchy...
First of all, POV is a magnificient program, and its
development (some call it "slow", I'd rather say
"thorough") doesn't hinder me.
Taking just its SDL, you can code a lot of stuff,
e.g. that depth-thing could be easily done by putting
a proper texture on all objects, or using plain white
as texture and some black fog...
Then, never forget that POV is FREEWARE, and that
no one gets paid to do their job. If guys like you and
me don't get enough time to work on an image for
about an hour a day, how can we expect to have people
move entire programs around in their brain to get something
working in an hour? I think, POV requires more time, just
because the actual programers have less than paid
ones (they've got another RL).
And, once POV is released, it runs pretty stable. Okay, this
new POV 3.5 seems to still have some rare bugs, but which
program doesn't? Every program with a good company behind
it gets a patch/update a few weeks after release. Beta-Testing
was pretty thorough, but still, not too many had the
patience to actually work on them (me included, I did use
the beta's, but didn't have the time to actually sit there and
track bugs, though I would have liked to contribute).
So, plainly put: it's a good idea to metion ideas, but it
is a bad one to start whining why this isn't done, or why
that isn't implemented... In my experience, the POV-Team
had good reasons for leaving this out, and putting something
else in, and I trust their expertise on this program.
And finally, if you need something implemented that badly,
do it! You can download the source, just go ahead!
I'm no pragrammer (yet), so I'm at the hands of the Team,
but I still like what they've done so far, and I can't wait
for further improvements. Nontheless, all good things require
time and patience. Things done in haste mostly are just waste.
I hope this prevents a perhaps too hot-headed debate about
why-not and that's-why. I like to keep things calm and steady.
Regards,
Tim
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <tim### [at] gmxde> wrote in news:3d812bbc@news.povray.org
> So, plainly put: it's a good idea to metion ideas, but it
> is a bad one to start whining why this isn't done, or why
> that isn't implemented...
Maybe just - it would be greate to have some tutorial like :
To write new shape, go to line in file ... and write this code : ...,
nowe write intersection tests in file/line... and add new token to parser
in line ...
Realy everyone who isn't involved in development of POV can easly get lost
in it's huge code.
Like in example - .txt format - with file/line is opening file, closes it,
parses it's name (and select extension), write line (or pixel - flush
buffer) ?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
web.3d811f95feedefd48531b09b0@news.povray.org...
> Yes, I'm getting your point...
Unfortunately, the point that many people *** do not get *** is that there
is a world of difference between having a cool idea and implementing it in a
patch made for personal use, and making it actually work in a
professional-quality software that will be used smoothly by thousands of
people.
To put it more bluntly :
- LOTS of people have "cool" ideas. A good number of people can write
patches too.
- FEW people have the necessary will, talent, or available free time, to go
further and create 100% usable code. For some reason, all the tedious stuff
that is also fundamental to software development (like comprehensive testing
and documentation) rarely gets done, which explains why a lot of cool stuff
doesn't get past the alpha stage. Lots of cool stuff doesn't get past
wishful thinking in fact.
Of course, anyone who wants to become one of those happy few who make
history is welcome...
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <git### [at] wanadoofr> wrote in news:3d812d2d@news.povray.org
> Of course, anyone who wants to become one of those happy few who make
> history is welcome...
How a litle help for fist time - can I get list of all places in code that
I need to modify to add new output format ? For developer of Pov it's a few
minute to list it, for me (and most others) - hours (days ?) of reading
throught entire code.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian wrote:
> 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?
>
>
IMHO, it would be better if the patches came out independently, got
tried out by the community a while, and eventually got consolidated
into a new MegaPOV type project unofficially for now.
The kind of beta testing required for a stable final release is quite
time consuming, and IIRC, plans for 4.0 were deferred a couple
years already to make 3.5 possible and bring POV-Ray back up to date
with all the patches. But the trouble is, there are *always* new patches
to suggest. If the POV-Team sets aside plans for 4.0 every time new
patches are suggested, 30 years from now, we'll all be using
POV 3.721234, and 4.0 will still be a distant dream.
In the meantime, if there are cool ideas not being explored, USE
THEM! Make cool things that cause people to go "hey, how did you
do that?" and actively encourage the patch writers to realize its
worth pursuing. If they become popular enough, they won't just
die. But the interval between now and 4.0 being complete will give
tons of time for further development on these patches, which is
also a good thing. Win-win situation, no?
--
@C[$F];
The Silver Tome :: http://www.silvertome.com
"You may sing to my cat if you like..."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles Fusner <cfu### [at] enternet> wrote in news:3D8### [at] enternet
> In the meantime, if there are cool ideas not being explored, USE
> THEM! Make cool things that cause people to go "hey, how did you
> do that?" and actively encourage the patch writers to realize its
> worth pursuing.
This is a very good idea, but with one disadvantage - if someone realy
needs i.e. path and some features from 3.5 - and he have to choose one of
them.
Maybe put togeather most up-to-date patches into POV 3.6 and release it as
very untested and unstable version for beta tests ? Then lots of work in
testing and maybe documentation, examples, includes can be done by users :)
--
#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:
> How a litle help for fist time - can I get list of all places in code that
> I need to modify to add new output format ? For developer of Pov it's a few
> minute to list it, for me (and most others) - hours (days ?) of reading
> throught entire code.
Nothing like that. If you really have experience programming and it
takes you an hour to locate the relevant code, I'd be surprised. Just
start with the parsing code and follow it through the program.
--
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:
> This is a very good idea, but with one disadvantage - if someone realy
> needs i.e. path and some features from 3.5 - and he have to choose one of
> them.
If they know the basics of how to program (and have the tools), they
could make their own version. Otherwise they will have to wait for
someone else or find a workaround.
> Maybe put togeather most up-to-date patches into POV 3.6 and release it as
> very untested and unstable version for beta tests ? Then lots of work in
> testing and maybe documentation, examples, includes can be done by users :)
No. Stupid, idiotic idea. No, no, no. It can be guaranteed that this
will not happen.
This is what MegaPOV and similar patch collections are for, to give
patches a place where they can develop and be refined to the point where
they are something useable for an official version. And making an
official version takes a lot of work, making sure there are no conflicts
or redundancies, working out the best syntax and internal design, and
then lots of testing before it is even suitable for public beta.
Suggesting that the POV Team just hack something together with no regard
to the future is just insulting.
--
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:
> > 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.
There are things a lot more than 2 people are interested in.
It might be interesting to implement as a curiousity, for the laugh
factor of implementing environment mapping in a raytracer. I do not see
how it could be useful.
> 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.
That's C++. This is only useful to programmers, the average user won't
have any use for it and won't be interested, and programmers have access
to libraries for manipulating formats already supported by POV. Or they
could write one: a TGA reader/writer is extremely simple to implement,
and the files could be manipulated in any good graphics program. As I
said, you shouldn't expect tons of interest in such a special-case
feature.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
