Am 20.06.2010 01:29, schrieb SharkD:
> If you search for tasks by SharkD at the bug tracker you'll see a bunch
> of feature request I've made.
>
> http://bugs.povray.org/

I'd like to encourage everyone to have a look there (not only on Shark's 
requests of course), and /vote/ on the features you like to see most. 
It's easier to track than sifting through newsgroup postings.

Post a reply to this message

Am 20.06.2010 12:33, schrieb SharkD:

>> Well, still Christoph Lipka had to close it because you never said so.
>> The logical assumption here then is that given Grimbert J�r�me (Le
>> Forgeron) provided a solution with existing SDL that the issue was
>> resolved.
>
> Grimbert was not suggesting a solution using SDL, he was suggesting a
> /course of action/ on how the feature should be implemented by devs!

I don't think so...

Post a reply to this message

Am 20.06.2010 11:14, schrieb SharkD:

> As for setting/overriding metrics, even an HTML coder can override
> things like x height using things like font-size-adjust and font-stretch.

You're forgetting that HTML browsers' main job is to display text. 
POV-Ray's main job is to render 3D images, which /occasionally/ may 
include text. Please understand that POV-Ray can therefore not 
double-act as a desktop publishing software.

But I do agree that a proper way to /get/ font metrics is a prerequisite 
to implement macros providing higher-level text layout capability.

As for font-size-adjust, this can easily achieved in POV-Ray by relative 
scaling; as for font-stretch, this can either be achieved by non-uniform 
scaling (e.g. faux condensed or faux expanded), or by choosing the 
appropriate font file (condensed or expanded font face, i.e. with 
individually designed glyphs).

>>> Ability to change the order of editor tabs by dragging them
>>
>> This is Windows only, I suppose.
>
> Why is that? Are Linux users too primitive to benefit from this feature?

Well, /POV-Ray for Linux/ is "too primitive" for users to benefit from 
the feature, because it doesn't come with a GUI at all.

Post a reply to this message

Am 20.06.2010 15:21, schrieb StephenS:

>> Subdivision support
> ....
> I like this, but is it natively thread safe? I very much like to see smp POV-Ray
> released, and then add more features that need development time to work with
> multi-threads.

There's still a difference between rejecting a feature request (which to 
me reads, "never going to happen"), and just keeping it unimplemented 
for now.

I think at present /all/ feature requests must be expected to be 
postponed until SMP POV-Ray (aka 3.7 final release) is out of the door, 
and any exception to this is just... well, an exception. So I see no 
reason to close feature requests on a "won't implement in 3.7" basis.

Post a reply to this message

On 6/20/2010 11:03 AM, clipka wrote:
> As for font-size-adjust, this can easily achieved in POV-Ray by relative
> scaling; as for font-stretch, this can either be achieved by non-uniform
> scaling (e.g. faux condensed or faux expanded), or by choosing the
> appropriate font file (condensed or expanded font face, i.e. with
> individually designed glyphs).

You're mistaken. font-size-adjust tweaks fonts in ways we can't do in 
Povray without knowing font metrics - specifically the font's x height.



-- 
http://isometricland.com

Post a reply to this message

On 6/20/2010 10:35 AM, clipka wrote:
> Am 20.06.2010 01:29, schrieb SharkD:
>> If you search for tasks by SharkD at the bug tracker you'll see a bunch
>> of feature request I've made.
>>
>> http://bugs.povray.org/
>
> I'd like to encourage everyone to have a look there (not only on Shark's
> requests of course), and /vote/ on the features you like to see most.
> It's easier to track than sifting through newsgroup postings.

Visitors will specifically have to search for closed feature requests, 
as otherwise they won't see all of them.

-- 
http://isometricland.com

Post a reply to this message

On 6/20/2010 5:44 AM, Thorsten Froehlich wrote:
>> "Clever use" means tedious work that gets repeated by users over and
>> over and over again. If it's so good then the devs can be "clever"
>> enough to add the feature.
>
> Well, I would be all for someone contributing a set of macros for the
> POV-Ray 3.7 include file collection to avoid any repetition.

OK, so it can be resolved with a set of macros. Is there any point of 
keeping the feature request closed then?

Post a reply to this message

On 6/20/2010 7:21 AM, Thorsten Froehlich wrote:
> If you flood the bug reporter with one-line feature requests, you cannot
> expect more than one-line responses. Don't expect people to worm all
> information out of you. Reports should be as complete and coherent as
> possible. This is the minimum courtesy you have to pay to those reading
> your ideas: In short, you want others to do something for you that they
> have no obligation to do for you. The best way to reach that goal is
> showing that you respect their valuable time. You expected the opposite.
>
> Thorsten

Look, I made most of my feature requests within the span of a week after 
having been *told* to go there under the assumption that there would be 
discussion, and you closed them within the span of a day with little or 
no discussion. If there was a problem with request descriptions being 
too short you could have just said so. And I don't see much evidence 
that *other* people besides you had much difficulty understanding them.



-- 
http://isometricland.com

Post a reply to this message

Am 20.06.2010 18:22, schrieb SharkD:
> On 6/20/2010 11:03 AM, clipka wrote:
>> As for font-size-adjust, this can easily achieved in POV-Ray by relative
>> scaling; as for font-stretch, this can either be achieved by non-uniform
>> scaling (e.g. faux condensed or faux expanded), or by choosing the
>> appropriate font file (condensed or expanded font face, i.e. with
>> individually designed glyphs).
>
> You're mistaken. font-size-adjust tweaks fonts in ways we can't do in
> Povray without knowing font metrics - specifically the font's x height.

That's exactly why I did concede that - quote - "a proper way to /get/ 
font metrics is a prerequisite to implement macros providing 
higher-level text layout capability."

And it's also a great example of why the actual layout functionality 
doesn't belong inside POV-Ray: Hey, I'm a 3D enthusiast, not a font 
expert. All I know is that font-size-adjust uniformly scales the font, 
so to me it's essentially a scaling operation, and I don't bother where 
the factor comes from.

Leave 3D magic to the 3D geeks & POV-Ray developers, and font magic to 
the font geeks & SDL macro programmers.

Post a reply to this message

Am 20.06.2010 18:24, schrieb SharkD:

>> I'd like to encourage everyone to have a look there (not only on Shark's
>> requests of course), and /vote/ on the features you like to see most.
>> It's easier to track than sifting through newsgroup postings.
>
> Visitors will specifically have to search for closed feature requests,
> as otherwise they won't see all of them.

... and of course they won't be able to vote on them, yes. Such is life.

Post a reply to this message

SharkD <pos### [at] gmailcom> wrote:
> On 6/20/2010 5:44 AM, Thorsten Froehlich wrote:
> >> Why is that? Are Linux users too primitive to benefit from this feature?
> >
> > Yes, they are! They have no editor supplied by POV-Ray!
>
> Didn't realize this, sorry.

We're not primitive.  We just enjoy using far superior text editors.  Both vim
and emacs kick povray's Windows editor's butt major time, complete with syntax
highligh, generalized textual completion and user code templates.  No point
degrading. :)

I don't think it'd be useful for povray developers to try to duplicate such
functionality either, just give us the glorious backend.

Post a reply to this message

On 6/20/2010 2:16 PM, nemesis wrote:
> We're not primitive.  We just enjoy using far superior text editors.  Both vim
> and emacs kick povray's Windows editor's butt major time, complete with syntax
> highligh, generalized textual completion and user code templates.  No point
> degrading. :)
>
> I don't think it'd be useful for povray developers to try to duplicate such
> functionality either, just give us the glorious backend.

I made that statement based on the faulty assumption that Linux users 
*do* in fact have a dedicated IDE/frontend.

-- 
http://isometricland.com

Post a reply to this message

SharkD <pos### [at] gmailcom> wrote:
> On 6/20/2010 2:16 PM, nemesis wrote:
> > We're not primitive.  We just enjoy using far superior text editors.  Both vim
> > and emacs kick povray's Windows editor's butt major time, complete with syntax
> > highligh, generalized textual completion and user code templates.  No point
> > degrading. :)
> >
> > I don't think it'd be useful for povray developers to try to duplicate such
> > functionality either, just give us the glorious backend.
>
> I made that statement based on the faulty assumption that Linux users
> *do* in fact have a dedicated IDE/frontend.

I know.  My point is that we don't need a weak frontend. :)

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> > Native support for mesh-based surface approximations

> You can already do this with a macro. Native support would have no benefit - 
> the probable assumption that a high quality mesh would be faster to generate 
> and then render compared to a native object (i.e. an isosurface) is incorrect.

  Given that meshes which approximate the same shape as a complex CSG
composed of other primitves sometimes renders faster than that CSG object,
I don't see how an isosurface would be even faster than that. On the
contrary, an isosurface with the same shape as the complex CSG most probably
would render at least an order of magnitude slower than the original CSG
object.

  Tesselating an isosurface to a mesh would probably be a slow'ish process,
but certainly not slower than rendering the isosurface. Then rendering the
mesh would in most cases be orders of magnitude faster than rendering the
original isosurface (after all, the rendering speed of a mesh is something
like logarithmically related to the amount of triangles, so even really
complex surfaces are going to render quite fast).

  Also there are advantages of tesselation other than faster rendering.
Among others, it would open up possibilities to efficiently simulate
non-linear transformations (applying a non-linear transformation to a CSG
is impossible, and on an isosurface makes the rendering slower, while on a
mesh it has little effect because the amount of triangles stays the same),
uv-mapping and exporting shapes to other formats.

  Of course the *major* problem here is: Which tesselation algorithm to use,
and how to implement it? And who is going to implement it?

  AFAIK the marching triangles algorithm is one of the best in existence
(while the marching cubes algorithm is one of the worst), and it's especially
suited for efficiently tesselating isosurfaces ("efficiently" meaning that it
generates an optimal amount of triangles, creating more on places with high
curvature and less in places with low curvature). It might also be usable
with CSG objects (although there are going to be surprising problems there.)
However, somebody would have to implement it.

-- 
                                                          - Warp

Post a reply to this message

On 21.06.10 14:30, Warp wrote:
> Thorsten Froehlich<tho### [at] trfde>  wrote:
>>> Native support for mesh-based surface approximations
>
>> You can already do this with a macro. Native support would have no benefit -
>> the probable assumption that a high quality mesh would be faster to generate
>> and then render compared to a native object (i.e. an isosurface) is incorrect.
>
>    Given that meshes which approximate the same shape as a complex CSG
> composed of other primitves sometimes renders faster than that CSG object,
> I don't see how an isosurface would be even faster than that. On the
> contrary, an isosurface with the same shape as the complex CSG most probably
> would render at least an order of magnitude slower than the original CSG
> object.

Not sure where you read isosurfaces are faster than CSG. Oh well :-(

	Thorsten

Post a reply to this message

nemesis wrote:
> We're not primitive.  We just enjoy using far superior text editors.  Both vim
> and emacs kick povray's Windows editor's butt major time, complete with syntax
> highligh, generalized textual completion and user code templates.  No point
> degrading. :)

FWIW, I use vim under Windows to do most of my original POV coding. The POV 
editor is nice for tweaks once the basic scene is running, tho. :-)

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 21.06.10 14:30, Warp wrote:
> > Thorsten Froehlich<tho### [at] trfde>  wrote:
> >>> Native support for mesh-based surface approximations
> >
> >> You can already do this with a macro. Native support would have no benefit -
> >> the probable assumption that a high quality mesh would be faster to generate
> >> and then render compared to a native object (i.e. an isosurface) is incorrect.
> >
> >    Given that meshes which approximate the same shape as a complex CSG
> > composed of other primitves sometimes renders faster than that CSG object,
> > I don't see how an isosurface would be even faster than that. On the
> > contrary, an isosurface with the same shape as the complex CSG most probably
> > would render at least an order of magnitude slower than the original CSG
> > object.

> Not sure where you read isosurfaces are faster than CSG. Oh well :-(

  "the probable assumption that a high quality mesh would be faster to
generate and then render compared to a native object (i.e. an isosurface)
is incorrect."

  If you claim that rendering an isosurface is faster than generating a
mesh from it and then rendering it, you are also implying that rendering
an isosurface is faster than rendering a (complex) CSG because there are
cases where meshes are faster to render than CSG. If meshes are faster than
CSG and isosurfaces are faster than meshes, it logically follows that
isosurfaces are faster than CSG.

  I don't really understand what you base your original claim that
isosurfaces are faster to render than generating a mesh and then rendering
the mesh on.

  There may be extreme cases where a really fast isosurface (one which is
extremely simple, ie. has a very low gradient, such as a sphere) is faster
to render than generating a mesh from it and then rendering the mesh because
of the overhead of the tesselation process (after all, the tesselation
algorithm requires some processing itself). However, that probably only
happens in extremely simple cases.

  In more complex cases tesselating the isosurface is more or less akin
to rendering it at low resolution (because usually it's enough to generate
a mesh which has triangles larger than pixels when projected onto the final
image). Also, when tesselating the isosurface probably needs to be solved
once per mesh vertex, while rendering it might be involve solving it several
times per pixel (eg. in self-reflection, refraction and shadowing situations).
If ray-mesh intersections are faster to compute than ray-isosurface
intersections, then in these cases tesselation + mesh rendering ought to
be faster than direct isosurface rendering.

  Even *if* for some reason tesselating the isosurface would be significantly
slower than rendering it, there may still be advantages of doing that because
the resulting mesh can be stored in a file and then read from there in
subsequent renders. Hence even in that case tesselation would be useful.

-- 
                                                          - Warp

Post a reply to this message

On 21.06.10 18:01, Warp wrote:
>>>     Given that meshes which approximate the same shape as a complex CSG
>>> composed of other primitves sometimes renders faster than that CSG object,
>>> I don't see how an isosurface would be even faster than that. On the
>>> contrary, an isosurface with the same shape as the complex CSG most probably
>>> would render at least an order of magnitude slower than the original CSG
>>> object.
>
>> Not sure where you read isosurfaces are faster than CSG. Oh well :-(
>
>    "the probable assumption that a high quality mesh would be faster to
> generate and then render compared to a native object (i.e. an isosurface)
> is incorrect."
>
>    If you claim that rendering an isosurface is faster than generating a
> mesh from it and then rendering it, you are also implying that rendering
> an isosurface is faster than rendering a (complex) CSG because there are
> cases where meshes are faster to render than CSG. If meshes are faster than
> CSG and isosurfaces are faster than meshes, it logically follows that
> isosurfaces are faster than CSG.

A very interesting conjecture. However, I have a real life, so you will have 
to discuss your conjecture with someone else.

	Thorsten

Post a reply to this message

On 21.06.10 18:01, Warp wrote:
>>>     Given that meshes which approximate the same shape as a complex CSG
>>> composed of other primitves sometimes renders faster than that CSG object,
>>> I don't see how an isosurface would be even faster than that. On the
>>> contrary, an isosurface with the same shape as the complex CSG most probably
>>> would render at least an order of magnitude slower than the original CSG
>>> object.
>
>> Not sure where you read isosurfaces are faster than CSG. Oh well :-(
>
>    "the probable assumption that a high quality mesh would be faster to
> generate and then render compared to a native object (i.e. an isosurface)
> is incorrect."
>
>    If you claim that rendering an isosurface is faster than generating a
> mesh from it and then rendering it, you are also implying that rendering
> an isosurface is faster than rendering a (complex) CSG because there are
> cases where meshes are faster to render than CSG. If meshes are faster than
> CSG and isosurfaces are faster than meshes, it logically follows that
> isosurfaces are faster than CSG.

A very interesting conjecture. However, I have a real life, so you will have 
to discuss your conjecture with someone else.

	Thorsten

Post a reply to this message

On 6/20/2010 7:10 AM, Thorsten Froehlich wrote:
>> Sure. And until then there's no reason for its removal from bugtracker.
>
> Its not removed. It is closed. All closed bugs are still visible.

Fine. Then there's no reason for it to be _closed_ on bugtracker. Smart guy.

-- 
http://isometricland.com

Post a reply to this message

On 6/21/2010 1:03 PM, Thorsten Froehlich wrote:
> A very interesting conjecture. However, I have a real life, so you will
> have to discuss your conjecture with someone else.
>
> Thorsten

Great. So items on bugtracker will survive based on whether a person has 
time in "real life" or, as implied in the other thread, on the attitude 
of the person who submitted the item. That sounds EXACTLY like the 
intended purpose of a software bug tracking system. In fact, why not 
also delete SVN branches because said person mentioned something about 
your mother?

-- 
http://isometricland.com

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 21.06.10 18:01, Warp wrote:
> >>>     Given that meshes which approximate the same shape as a complex CSG
> >>> composed of other primitves sometimes renders faster than that CSG object,
> >>> I don't see how an isosurface would be even faster than that. On the
> >>> contrary, an isosurface with the same shape as the complex CSG most probably
> >>> would render at least an order of magnitude slower than the original CSG
> >>> object.
> >
> >> Not sure where you read isosurfaces are faster than CSG. Oh well :-(
> >
> >    "the probable assumption that a high quality mesh would be faster to
> > generate and then render compared to a native object (i.e. an isosurface)
> > is incorrect."
> >
> >    If you claim that rendering an isosurface is faster than generating a
> > mesh from it and then rendering it, you are also implying that rendering
> > an isosurface is faster than rendering a (complex) CSG because there are
> > cases where meshes are faster to render than CSG. If meshes are faster than
> > CSG and isosurfaces are faster than meshes, it logically follows that
> > isosurfaces are faster than CSG.

> A very interesting conjecture. However, I have a real life, so you will have 
> to discuss your conjecture with someone else.

  I wonder if this will be a permanent pattern from this time forward:
Every time you make a post and I respond to it, you see me attacking you,
regardless of what my intentions truly are and what the topic in question
is, and when I try to explain myself, you invariable resort to some kind
of meta-discussion instead of discussing about the relevant subject at hand.

-- 
                                                          - Warp

Post a reply to this message

On 21.06.10 19:06, SharkD wrote:
> On 6/20/2010 7:10 AM, Thorsten Froehlich wrote:
>>> Sure. And until then there's no reason for its removal from bugtracker.
>>
>> Its not removed. It is closed. All closed bugs are still visible.
>
> Fine. Then there's no reason for it to be _closed_ on bugtracker. Smart
> guy.

You real think insulting me will get you any further? You already misbehaved 
twice. First by vandalizing the Wiki, the by vandalizing the bug tracker. No 
need to vandalize the newsgroups as well.

	Thorsten

Post a reply to this message

On 6/21/2010 1:16 PM, Warp wrote:
>    I wonder if this will be a permanent pattern from this time forward:
> Every time you make a post and I respond to it, you see me attacking you,
> regardless of what my intentions truly are and what the topic in question
> is, and when I try to explain myself, you invariable resort to some kind
> of meta-discussion instead of discussing about the relevant subject at hand.
>

It's because you're invading his precious territory.

-- 
http://isometricland.com

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Of course the *major* problem here is: Which tesselation algorithm to use,
> and how to implement it? And who is going to implement it?

oh, the last one is easy:  I vote for the pov-team. :)

Post a reply to this message

I'd like to throw my 10c in here WRT to this thread (which is getting a
little long so I won't attempt to cover all the issues).

The way the bugtracker works with regard to 'closed' bugs isn't easily
altered (in that they don't turn up in searches by default). I will attempt
to rectify this later.

Comments on closed bugs were previously not available; they are now -
hopefully this will allow easier feedback.

When reporting a bug or making a feature request please try to be detailed
and especially include platform and version details.

Also, it would help us a bit if closely-related feature requests were
grouped together; e.g. the recent requests for Windows UI enhancements with
respect to the editor could reasonably have been put into a single request
(all at once or via editing a bug later).

Before posting a feature or bug request, it might be useful to sound it out
with other users first. This doesn't mean you have to run it by us, but
getting other user's feedback can help improve the quality of the requests
we get. This isn't a hard and fast rule, it's just a suggestion.

Please keep in mind that we (like most open-source projects) are
under-manned so doing things in such a way as to make it easier for us to
track helps. The bugtracker is of course there for that reason, but as I've
pointed out it's important to make the reports as useful for us as
reasonably possible. Higher quality reports == more chance we'll pay close
attention.

-- Chris

Post a reply to this message

On 6/21/2010 4:09 PM, Chris Cason wrote:
> Also, it would help us a bit if closely-related feature requests were
> grouped together; e.g. the recent requests for Windows UI enhancements with
> respect to the editor could reasonably have been put into a single request
> (all at once or via editing a bug later).

No, as per the bug reporting instructions which say, "Only report one 
bug or request one feature per task."

-- 
http://isometricland.com

Post a reply to this message

On 23.06.10 01:11, SharkD wrote:
> On 6/21/2010 4:09 PM, Chris Cason wrote:
>> Also, it would help us a bit if closely-related feature requests were
>> grouped together; e.g. the recent requests for Windows UI enhancements
>> with
>> respect to the editor could reasonably have been put into a single
>> request
>> (all at once or via editing a bug later).
>
> No, as per the bug reporting instructions which say, "Only report one
> bug or request one feature per task."

You know whom you are talking to, don't you? - This reminds me of my 
favourite quote: "The ability to speak does not make you intelligent."
I wonder if this also applies to writing? Hmm...

Anyhow, here is how you could have summarized feature requests 138, 139 and 
140 in a single report. It is really easy, I am sure next time you can 
follow these instructions:

1. Power up brain.
2. Wait for brain to boot.
3. Enable ability to think.
4. Think about the features "Rename file", "Delete file", "Reload file".
5. Make sure brain concludes the features belong in the "File" menu.
6. Think about the "File" menu and conclude it groups file functions.
7. Think about feature request to extend the "File" menu.
8. Make sure to name "Rename", "Delete" and "Reload" possible extensions.
9. Let brain command body to type and submit feature request.
10. Disable ability to think.
11. Power down brain.
12. Wait for brain to power down.
13. Return to normal zombie activities.

	Thorsten

Post a reply to this message

On 6/23/2010 12:18 PM, Thorsten Froehlich wrote:

> You know whom you are talking to, don't you? - This reminds me of my
> favourite quote: "The ability to speak does not make you intelligent."
> I wonder if this also applies to writing? Hmm...

...and someone could just as easily have bitched about /not/ reporting 
them as separate tasks. Was there a way to know this beforehand? No. Are 
you an asshole? Yes.

-- 
http://isometricland.com

Post a reply to this message

On 6/21/2010 4:09 PM, Chris Cason wrote:
> Before posting a feature or bug request, it might be useful to sound it out
> with other users first. This doesn't mean you have to run it by us, but
> getting other user's feedback can help improve the quality of the requests
> we get. This isn't a hard and fast rule, it's just a suggestion.

There is a discussion area in bugtracker for this, no?

-- 
http://isometricland.com

Post a reply to this message

Am 23.06.2010 19:08, schrieb SharkD:
> On 6/21/2010 4:09 PM, Chris Cason wrote:
>> Before posting a feature or bug request, it might be useful to sound
>> it out
>> with other users first. This doesn't mean you have to run it by us, but
>> getting other user's feedback can help improve the quality of the
>> requests
>> we get. This isn't a hard and fast rule, it's just a suggestion.
>
> There is a discussion area in bugtracker for this, no?

Not really.

There is a feature to allow other users and/or developers to comment on 
bugs & feature request, but this is primarily intended for providing 
additional information, or feedback on the current status. For proper 
discussions, it lacks the necessary publicity. (When was the last time 
you just browsed the bugtracker just to see if there was some 
interesting discussion going on in some of the entries?)

As someone else already said, the POV-Ray community is strongest in the 
newsgroups.

Post a reply to this message

On 6/23/2010 2:26 PM, clipka wrote:
> Not really.
>
> There is a feature to allow other users and/or developers to comment on
> bugs & feature request, but this is primarily intended for providing
> additional information, or feedback on the current status. For proper
> discussions, it lacks the necessary publicity. (When was the last time
> you just browsed the bugtracker just to see if there was some
> interesting discussion going on in some of the entries?)
>
> As someone else already said, the POV-Ray community is strongest in the
> newsgroups.

True, but as you can see threads here have difficulty staying on-topic.


-- 
http://isometricland.com

Post a reply to this message

SharkD wrote:
> True, but as you can see threads here have difficulty staying on-topic.
>
Unless human nature has changed while I wasn't paying attention, all discussions
have difficulty staying on topic.  I believe this is why Robert invented Rules
of Order...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   Of course the *major* problem here is: Which tesselation algorithm to use,
> > and how to implement it? And who is going to implement it?

> oh, the last one is easy:  I vote for the pov-team. :)

  As if they didn't have their hands full of work already...

-- 
                                                          - Warp

Post a reply to this message

>> No, as per the bug reporting instructions which say, "Only report one
>> bug or request one feature per task."
>
> You know whom you are talking to, don't you? - This reminds me of my 
> favourite quote: "The ability to speak does not make you intelligent."
> I wonder if this also applies to writing? Hmm...

Wouldn't it be more productive to try and address the cause of the ambiguity 
(ie add Chris' point about grouping similar requests to the bug tracker 
instructions) rather than calling someone stupid who is trying to help 
improve POV?

Post a reply to this message

On 6/25/2010 3:52 AM, scott wrote:
> Wouldn't it be more productive to try and address the cause of the
> ambiguity (ie add Chris' point about grouping similar requests to the
> bug tracker instructions) rather than calling someone stupid who is
> trying to help improve POV?
>
>

You are not showing sufficient timorousness toward the master!

-- 
http://isometricland.com

Post a reply to this message

On 25.06.10 09:52, scott wrote:
>>> No, as per the bug reporting instructions which say, "Only report one
>>> bug or request one feature per task."
>>
>> You know whom you are talking to, don't you? - This reminds me of my
>> favourite quote: "The ability to speak does not make you intelligent."
>> I wonder if this also applies to writing? Hmm...
>
> Wouldn't it be more productive to try and address the cause of the
> ambiguity (ie add Chris' point about grouping similar requests to the
> bug tracker instructions) rather than calling someone stupid who is
> trying to help improve POV?

No, it would not be more productive because SharkD's goal is not to help, 
but to game the system: <http://en.wikipedia.org/wiki/Wikipedia%3AGAME>. How 
do I conclude his main goal is causing disruption? - He has used the tactic 
of malicious compliance after he was prohibited from vandalizing the Wiki. 
Next he moved to the bug tracker. As such, his "help" simply is not wanted 
because he is not serious in helping the POV-Ray community, but rather to 
poison it.

	Thorsten

Post a reply to this message

On 6/25/2010 2:20 PM, Thorsten Froehlich wrote:
> No, it would not be more productive because SharkD's goal is not to
> help, but to game the system:
> <http://en.wikipedia.org/wiki/Wikipedia%3AGAME>. How do I conclude his
> main goal is causing disruption? - He has used the tactic of malicious
> compliance after he was prohibited from vandalizing the Wiki. Next he
> moved to the bug tracker. As such, his "help" simply is not wanted
> because he is not serious in helping the POV-Ray community, but rather
> to poison it.
>
> Thorsten

THAT is what I consider to be malicious! WTF, gaming the system?? You 
seriously think I have anything to gain by doing this?

And I was specifically directed /to/ the bugtracker, not by my own decision.

It sounds more to me like YOU are gaming the system, using your position 
as a leader in the POV community to abuse people around you.

-- 
http://isometricland.com

Post a reply to this message

On 6/19/2010 8:42 PM, stbenge wrote:
> You left out camera pigment, projection pigment, explicit image filename
> output for animations (for stuff like CA), last image buffer access... I
> guess I should make a few requests of my own. If I could patch POV-Ray
> myself, I would!

Are these MegaPOV features? I haven't ever used MegaPOV.


-- 
http://isometricland.com

Post a reply to this message

I've compiled a list of points made here and in the thread over in 
p.general:

http://wiki.povray.org/content/Knowledgebase:POV-Ray_Feature_Requests

Is this satisfactory?

Post a reply to this message

SharkD wrote:
> It sounds more to me like YOU are gaming the system, using your position 
> as a leader in the POV community to abuse people around you.

(The sounds of munching popcorn ensue.)

-- 
Darren New, San Diego CA, USA (PST)
    C# - a language whose greatest drawback
    is that it's best implementation comes
    from a company that doesn't hate Microsoft.

Post a reply to this message

Am 25.06.2010 20:20, schrieb Thorsten Froehlich:

> No, it would not be more productive because SharkD's goal is not to
> help, but to game the system:
> <http://en.wikipedia.org/wiki/Wikipedia%3AGAME>. How do I conclude his
> main goal is causing disruption? - He has used the tactic of malicious
> compliance after he was prohibited from vandalizing the Wiki. Next he
> moved to the bug tracker. As such, his "help" simply is not wanted
> because he is not serious in helping the POV-Ray community, but rather
> to poison it.

Hm... so, for instance, summarizing the (more constructive) results of 
this discussion on the Wiki is no help?

I prefer to disagree.

And as we're on it inferring a person's motives from their actions alone 
and right in their face: I'm more in for "don't assume malice where 
stupidity will suffice".

(Sorry Mike, just wording it this way for the sake of the quote.)

Post a reply to this message

Am 25.06.2010 23:18, schrieb SharkD:
> I've compiled a list of points made here and in the thread over in
> p.general:
>
> http://wiki.povray.org/content/Knowledgebase:POV-Ray_Feature_Requests
>
> Is this satisfactory?

Looks like a good summary to me. While a lot of it are actually quotes, 
I think they're well-picked, and you did a good job at "polishing" them up.

Post a reply to this message

On 6/25/2010 9:25 PM, clipka wrote:
> Am 25.06.2010 23:18, schrieb SharkD:
>> I've compiled a list of points made here and in the thread over in
>> p.general:
>>
>> http://wiki.povray.org/content/Knowledgebase:POV-Ray_Feature_Requests
>>
>> Is this satisfactory?
>
> Looks like a good summary to me. While a lot of it are actually quotes,
> I think they're well-picked, and you did a good job at "polishing" them up.

Thank you!


-- 
http://isometricland.com

Post a reply to this message

SharkD wrote:
> On 6/19/2010 8:42 PM, stbenge wrote:
>> You left out camera pigment, projection pigment, explicit image filename
>> output for animations (for stuff like CA), last image buffer access... I
>> guess I should make a few requests of my own. If I could patch POV-Ray
>> myself, I would!
> 
> Are these MegaPOV features? I haven't ever used MegaPOV.

Only the camera and projection pigments are.

Post a reply to this message

Le 2010-06-19 19:29, SharkD a écrit :
> If you search for tasks by SharkD at the bug tracker you'll see a bunch
> of feature request I've made.
>
> http://bugs.povray.org/
>
> Here's a list if you don't want to do the search:
>
> Option to render pixels randomly, or in Nth pixel
Why?
Maybe try with the crand statement in the finish, applied to the whole 
scene. Use a large value for the crand.

> Native support for mesh-based surface approximations
Slow!
Why? To create the mesh, you need to evaluate the base object, about as 
long as rendering it, maybe even longer than rendering. When you render 
the object, you only render the visible part of it. When you convert it 
to a mesh, you also need to evaluate all the parts that you don't see.
Then, you need to render the mesh, fast part.
Then, the generated mesh will take a large amount of memory and you may 
not beneficiate fron instancing the mesh, whitch, in turn, can force the 
use of the swap file and that's SLOWWW!
A box renders very fast and take a small amount of memory. It's mesh 
version would take about the same time to render, and take the memory 
needed for it's 12 triangles in addition to the material used and the 
transform matrix.
A sphere is defined as a center point, a radius and it's material and 
maybe a transformation matrix if it's unevenly scaled or rotated. An 
acceptable mesh version can easily need over 100 triangles, and any 
transpate will need a transform matrix.
Converting an isosurface to a mesh imply scaning it's whole surface, 
even the back parts and parts hiden by other objects.

> Subdivision support
Interesting

> String concatenation operator
This one is available in the current betas for some times now.
#declare String=String1+String2;
With 3.6, there is the concat(String1, String2,...)

>
> I'd like to see some thoughts/comments on these requests.
>

Alain

Post a reply to this message

Am 26.06.2010 19:48, schrieb Alain:

>> String concatenation operator
> This one is available in the current betas for some times now.
> #declare String=String1+String2;

I'm sorry to disappoint you, but did you actually try?

What the 3.7 betas have by now is string /comparison/ operators. 
Concatenation is still only supported via the concat() function.

Post a reply to this message

Le 2010-06-26 16:00, clipka a écrit :
> Am 26.06.2010 19:48, schrieb Alain:
>
>>> String concatenation operator
>> This one is available in the current betas for some times now.
>> #declare String=String1+String2;
>
> I'm sorry to disappoint you, but did you actually try?
>
> What the 3.7 betas have by now is string /comparison/ operators.
> Concatenation is still only supported via the concat() function.
Oups :(

Post a reply to this message

>>>> No, as per the bug reporting instructions which say, "Only report one
>>>> bug or request one feature per task."
>>>
>>> You know whom you are talking to, don't you? - This reminds me of my
>>> favourite quote: "The ability to speak does not make you intelligent."
>>> I wonder if this also applies to writing? Hmm...
>>
>> Wouldn't it be more productive to try and address the cause of the
>> ambiguity (ie add Chris' point about grouping similar requests to the
>> bug tracker instructions) rather than calling someone stupid who is
>> trying to help improve POV?
>
> No, it would not be more productive because SharkD's goal is not to help,

What does his goal have to do with it?  If you'd updated the bug tracker 
instructions with Chris' suggestion rather than writing a driveling reply 
about SharkD we might be getting somewhere!  Hint: Updating the instructions 
will make it clearer for future users, calling someone stupid won't (in fact 
it might even drive people away from making suggestions)

Post a reply to this message

On 28.06.10 15:05, scott wrote:
>> No, it would not be more productive because SharkD's goal is not to help,
>
> What does his goal have to do with it?

The goal to provide all of these resources is to share knowledge for the 
mutual benefit of users and developers of POV-Ray. They do not exist for 
personal entertainment of other interests (exception: the newsgroup 
povray.off-topic).

> If you'd updated the bug tracker
> instructions with Chris' suggestion rather than writing a driveling
> reply about SharkD we might be getting somewhere! Hint: Updating the
> instructions will make it clearer for future users, calling someone
> stupid won't

Writing explicit rules to cover every possible case, or every case that ever 
comes up, is a pure waste of time and the net result is nobody will read 
them. I think I made the point clear on how explicit rules could be ;-)

And there is a difference between pointing that out to someone and calling 
them stupid. However, resorting to name-calling as a response is a dead-end 
solution!

 > (in fact it might even drive people away from making suggestions)

And yes, a community is not about accepting someone who refuses to fit in.

Common sense suggests that making suggestions is way different from stuffing 
them into everybody's face in every possible way.

	Thorsten

Post a reply to this message