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:

Master scene unit system variable
Set and get font metrics
Add "POV-Ray" metatags to images
Table of Contents in each page of the docs
More library paths, wildcards
Option to render pixels randomly, or in Nth pixel
#ELSEIF statement
variable number of parameters in macros
System variable to track whether a file has been included
Explicit #RETURN statement inside macros
Expandable arrays
Mixed-type arrays
Hash arrays
Ability to change the order of editor tabs by dragging them
Native support for mesh-based surface approximations
Subdivision support
INI option to overlay render information on output image
Right-click menu when clicking on editor tab
String concatenation operator
atand function
"Rename" option in File menu

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

-- 
http://isometricland.com

Post a reply to this message

Here's two more:

"Delete" option in File menu - for deleting (and closing) the current file
"Reload" option in File menu - for reloading the current file from disk, 
discarding any changes since the last save

-- 
http://isometricland.com

Post a reply to this message

SharkD wrote:
> If you search for tasks by SharkD at the bug tracker you'll see a bunch 
> of feature request I've made.
> 
> Here's a list if you don't want to do the search:
> 
> System variable to track whether a file has been included

Seconded.

> Expandable arrays

As in dynamic? Oh yeah, that would be nice.

> Native support for mesh-based surface approximations

Would it be like an isosurface object?

> Subdivision support

This is /soooo/ needed it's ridiculous.

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

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!

Post a reply to this message

> SharkD wrote:
> Subdivision support

There was a great unofficial version... POV-Sub... which did this. As I 
recall, it was very fast. I would still be using it today, but 3.7b does 
more, and runs on more cores. One cool thing about that particular 
enhancement was that you could perform smoothing on any custom mesh 
without having to puzzle out what normal vector a particular point 
needed. It did this even without actually needing to subdivide a mesh.

http://www.cise.ufl.edu/~xwu/Pov-Sub/

Post a reply to this message

On 6/19/2010 7:29 PM, SharkD wrote:
> 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:
>
> Master scene unit system variable
> Set and get font metrics
> Add "POV-Ray" metatags to images
c> Table of Contents in each page of the docs
> More library paths, wildcards
> Option to render pixels randomly, or in Nth pixel
> #ELSEIF statement
a> variable number of parameters in macros
> System variable to track whether a file has been included
> Explicit #RETURN statement inside macros
> Expandable arrays
> Mixed-type arrays
> Hash arrays
b> Ability to change the order of editor tabs by dragging them
> Native support for mesh-based surface approximations
> Subdivision support
> INI option to overlay render information on output image
> Right-click menu when clicking on editor tab
> String concatenation operator
> atand function
b> "Rename" option in File menu
>
> I'd like to see some thoughts/comments on these requests.
>

a) You can pass include files as strings and then check #isdef for 
variables you want to be optional.

b) I second them

c) How about a link to the TOC instead?

Post a reply to this message

"SharkD" <pos### [at] gmailcom> schreef in bericht 
news:4c1d52c5$1@news.povray.org...
> Here's a list if you don't want to do the search:
>
> Master scene unit system variable
> Set and get font metrics
> Add "POV-Ray" metatags to images
> Table of Contents in each page of the docs
***> More library paths, wildcards
> Option to render pixels randomly, or in Nth pixel
> #ELSEIF statement
***> variable number of parameters in macros
***> System variable to track whether a file has been included
***> Explicit #RETURN statement inside macros
> Expandable arrays
> Mixed-type arrays
> Hash arrays
***> Ability to change the order of editor tabs by dragging them
> Native support for mesh-based surface approximations
***> Subdivision support
> INI option to overlay render information on output image
***> Right-click menu when clicking on editor tab
> String concatenation operator
> atand function
***> "Rename" option in File menu
>
> I'd like to see some thoughts/comments on these requests.

I suppose I second this list although I am not sure what all requests can 
do. I certainly would like more library paths or the possibility to use 
wildcards there, for instance. I put *** by those I particularly like.

Thomas

Post a reply to this message

On 20.06.10 01:29, SharkD wrote:
> 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:
>
> Master scene unit system variable

This feature was already discussed before - and rejected. POV-ray is a 
unit-less system by design.

> Set and get font metrics

You cannot set them because there is nothing to set in a finished font. You 
can only set font metrics in a font editor. If you want to apply effects to 
text objects, you can transform individual characters with a macro. Getting 
the essential font metrics is already possible with clever use of the 
min_extent and max_extent functions.

> Table of Contents in each page of the docs

Already there, supplied by the system in Windows help docs (given you report 
for Windows). You can also use the PDF docs, which have this, as do the Mac 
help docs.

> More library paths, wildcards

There was information missing in your feature request. Please add it there.

> Explicit #RETURN statement inside macros

You are misunderstanding that macros are not functions. There is no such 
thing as a return from a macro.

> Mixed-type arrays

Already possible.

> Ability to change the order of editor tabs by dragging them

This is Windows only, I suppose.

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

> Right-click menu when clicking on editor tab

On Windows, I guess?

> atand function

This is the degree based version of atan. Use the radians and degrees functions.

	Thorsten

Post a reply to this message

On 6/20/2010 3:34 AM, Thomas de Groot wrote:
> I suppose I second this list although I am not sure what all requests can
> do. I certainly would like more library paths or the possibility to use
> wildcards there, for instance. I put *** by those I particularly like.
>
> Thomas

About half the requests got bulk-closed by Thorsten Fröhlich, so alas 
there is no way of bringing your opinions to anyone's attention (at 
least "officially").

-- 
http://isometricland.com

Post a reply to this message

On 6/20/2010 4:54 AM, Thorsten Froehlich wrote:
> You cannot set them because there is nothing to set in a finished font.
> You can only set font metrics in a font editor. If you want to apply
> effects to text objects, you can transform individual characters with a
> macro. Getting the essential font metrics is already possible with
> clever use of the min_extent and max_extent functions.

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

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


> Already there, supplied by the system in Windows help docs (given you
> report for Windows). You can also use the PDF docs, which have this, as
> do the Mac help docs.

I was talking about sub-topics within extremely long pages. No, the 
Windows help docs can't help you there as they don't track what topic 
you're reading at any given moment.

>> More library paths, wildcards
>
> There was information missing in your feature request. Please add it there.

What information?


>> Explicit #RETURN statement inside macros
>
> You are misunderstanding that macros are not functions. There is no such
> thing as a return from a macro.

OK, I see now that a return statement wouldn't work in a macro. A macro 
can return an arbitrary block of code that could be completely unstructured.


>> Mixed-type arrays
>
> Already possible.

Really? You mean the following will work?

#local new_array = array[3]
{
	"foo", bar(), 20
}


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


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

Pray tell me then why people have taken the time to write these complex 
macros if there is no benefit? Just this week I've been told at least a 
half a dozen times that my scenes would render faster if I replaced my 
objects with meshes.


>> Right-click menu when clicking on editor tab
>
> On Windows, I guess?

Guess why?


>> atand function
>
> This is the degree based version of atan. Use the radians and degrees
> functions.

There are already sind, tand, cosd, tan2d, etc. Why not also tand? Too 
conspicuous for you?


-- 
http://isometricland.com

Post a reply to this message

On 20.06.10 10:57, SharkD wrote:
> On 6/20/2010 3:34 AM, Thomas de Groot wrote:
>> I suppose I second this list although I am not sure what all requests can
>> do. I certainly would like more library paths or the possibility to use
>> wildcards there, for instance. I put *** by those I particularly like.
>
> About half the requests got bulk-closed by Thorsten Fröhlich, so alas
> there is no way of bringing your opinions to anyone's attention (at
> least "officially").

The requests were not "bulk-closed". There is an explanation for each and 
every one of them. Several of the features you requested are outside the 
scope of POV-Ray as a renderer, such as editing fonts, others were 
misconceptions about macros, and yet others were requests for already 
existing features, like being able to pass degrees to atan. And yet another 
request was a duplicate of an existing feature request.

Also, please note that you previously made feature requests, but when 
prompted for what you actually wanted with them, remained silent, such as 
for feature request #63. It may seem tempting to create one line ideas, but 
what that really shows is that you have never actually thought about the 
usefulness of the idea.

A bit more is required than a single sentence or very short paragraph if you 
want to start any sort of discussion beyond "I like this" or "I don't like 
that". The point of such discussion is that sometimes it will reveal that 
the person who made the suggestion had a misconception about how a feature 
works, or that there might even be a trivial existing solution. Your atand 
feature request would be such an example where you could have profited from 
a discussion before suggesting the feature that already exists by means of 
the radians function, and can be extremely quickly added for convenience, 
should you really desire it:

#declare atand = function(a) { atan(radians(a)) }

	Thorsten

Post a reply to this message

Le 20/06/2010 11:14, SharkD nous fit lire :
> On 6/20/2010 4:54 AM, Thorsten Froehlich wrote:
>>> Explicit #RETURN statement inside macros
>>
>> You are misunderstanding that macros are not functions. There is no such
>> thing as a return from a macro.
> 
> OK, I see now that a return statement wouldn't work in a macro. A macro
> can return an arbitrary block of code that could be completely
> unstructured.
> 

BS: a macro does *NOT* return, it get expanded.
It can be expanded to any thing.
If you think of macro as functions, you are deceiving yourself and
preparing for more problems.

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

Hello.... anybody inside ? There is no Linux front-end.
(But povclipse is a nice module for eclipse & povray)

> 
>>> 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.
> 
> Pray tell me then why people have taken the time to write these complex
> macros if there is no benefit? Just this week I've been told at least a
> half a dozen times that my scenes would render faster if I replaced my
> objects with meshes.
> 

The problem is that you have to take into account the time to generate
the mesh itself (otherwise it would be cheating)... or work like other
renderers: with mesh file (already generated) only.

Mesh is a cheap inaccurate solution when you can have an exact
mathematical shape instead. They have their interest, but are not panacea.

When all you have is a hammer, everything looks like a nail.
That's what happens within other renderer: all they support is a
triangle, so only meshes are available.
(even Nurbs get transformed into collection of triangles)

Post a reply to this message

On 20.06.10 11:14, SharkD wrote:
> On 6/20/2010 4:54 AM, Thorsten Froehlich wrote:
>> You cannot set them because there is nothing to set in a finished font.
>> You can only set font metrics in a font editor. If you want to apply
>> effects to text objects, you can transform individual characters with a
>> macro. Getting the essential font metrics is already possible with
>> clever use of the min_extent and max_extent functions.
>
> "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.

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

Yes, it is called "scale" in POV-Ray ;-)

>> Already there, supplied by the system in Windows help docs (given you
>> report for Windows). You can also use the PDF docs, which have this, as
>> do the Mac help docs.
>
> I was talking about sub-topics within extremely long pages. No, the
> Windows help docs can't help you there as they don't track what topic
> you're reading at any given moment.

Hmm, I am not sure how a table of contents at the top of such a page (as you 
suggested) would help you keep track of where you are on that page. I know 
that PDF table of content views get updated as you move through the 
document, but I am not aware of any HTML feature (sans JavaScript) that 
could do this interactively.

>>> More library paths, wildcards
>>
>> There was information missing in your feature request. Please add it
>> there.
>
> What information?

Please refer to the bug report. What is needed is the version of POV-ray you 
are using, and the error message displayed. The background here is (as 
explained in the comment for that feature request) that the code does not 
have a limit of 20 paths internally, so the problem must be coming from some 
platform specific code that has not been updated. - It is correct that there 
was such a limit in 3.6, but you reported the problem against 3.7 beta where 
it should be exist. That is also my I changed the "feature request" to 
"possible bug".

>>> Explicit #RETURN statement inside macros
>>
>> You are misunderstanding that macros are not functions. There is no such
>> thing as a return from a macro.
>
> OK, I see now that a return statement wouldn't work in a macro. A macro
> can return an arbitrary block of code that could be completely
> unstructured.

Yes.

>>> Mixed-type arrays
>>
>> Already possible.
>
> Really? You mean the following will work?
>
> #local new_array = array[3]
> {
> "foo", bar(), 20
> }

No, this syntax will not work. I actually just noticed that i added the 
explanation to report 127 (rather than 128). Among other things, you can do 
things like this:

#declare foo = array[2];
#declare foo[0] = array[2];
#declare foo[1] = array[7];
#declare foo[0][0] = 2;
#declare foo[1][6] = sphere{1,1}

Reformatting this syntax to something close to what you are looking for is 
possible. You might want to open another thread here for such a discussion, 
or discuss it here.

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

Yes, they are! They have no editor supplied by POV-Ray!

>>> 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.
>
> Pray tell me then why people have taken the time to write these complex
> macros if there is no benefit? Just this week I've been told at least a
> half a dozen times that my scenes would render faster if I replaced my
> objects with meshes.

By whom, and where?

>>> atand function
>>
>> This is the degree based version of atan. Use the radians and degrees
>> functions.
>
> There are already sind, tand, cosd, tan2d, etc. Why not also tand? Too
> conspicuous for you?

Well, I see now. You really need to write more than "There already exist 
atan, atan2 and atan2d functions, why not atand?" as a feature request. Both 
"atan" and "atan2" are built in functions. "atand" is not. Now that you 
mentioned the other ones, I had a chance to notice that these functions are 
indeed defined - in "math.inc". That would have been the minimum additional 
necessary information needed to figure out what you were up to. Now I know, 
and indeed have simply added it. So in the next beta you should find a
#declare atand = function (x) {degrees(atan(x))}
in "math.inc".

	Thorsten

Post a reply to this message

On 6/20/2010 5:25 AM, Thorsten Froehlich wrote:
> The requests were not "bulk-closed". There is an explanation for each
> and every one of them. Several of the features you requested are outside
> the scope of POV-Ray as a renderer, such as editing fonts, others were
> misconceptions about macros, and yet others were requests for already
> existing features, like being able to pass degrees to atan. And yet
> another request was a duplicate of an existing feature request.

Sorry, I though more than the 8 of my requests got closed. As for the 
items one by one:

As for font metrics, the request was for getting /and/ setting the values.

The request was for a native "atan" function. Since the function doesn't 
exist, I can't see how it's an "existing feature".

There was no duplicate request. One request was for metadata inside the 
image metatag parameters. The other request was for scene data overlaid 
on top of the image.


> Also, please note that you previously made feature requests, but when
> prompted for what you actually wanted with them, remained silent, such
> as for feature request #63. It may seem tempting to create one line
> ideas, but what that really shows is that you have never actually
> thought about the usefulness of the idea.

That's the only request anyone "prompted" me about as far as I can see. 
Judging by the other replies people seem to have understood the request 
properly.


> A bit more is required than a single sentence or very short paragraph if
> you want to start any sort of discussion beyond "I like this" or "I
> don't like that".

I'm willing to discuss things, but if no one replies other than one-line 
closing message there's not much I can do.


-- 
http://isometricland.com

Post a reply to this message

On 20.06.10 11:48, SharkD wrote:
> On 6/20/2010 5:25 AM, Thorsten Froehlich wrote:
>> The requests were not "bulk-closed". There is an explanation for each
>> and every one of them. Several of the features you requested are outside
>> the scope of POV-Ray as a renderer, such as editing fonts, others were
>> misconceptions about macros, and yet others were requests for already
>> existing features, like being able to pass degrees to atan. And yet
>> another request was a duplicate of an existing feature request.
>
> Sorry, I though more than the 8 of my requests got closed. As for the
> items one by one:
>
> As for font metrics, the request was for getting /and/ setting the values.

Yes, but as was explained there by Christoph Lipka and me, you cannot set 
them in POV-Ray because they are part of the font. What you can do though is 
use a macro for both getting them and modifying a text object accordingly. 
That is pretty much how they are displayed by other programs as well. I.e. 
to change the spacing between characters, in POV-Ray you write a macro that 
takes a string and then creates text objects for each character (internally 
a POV text object is nothing else but a collection of character objects) 
with a different spacing.

> The request was for a native "atan" function. Since the function doesn't
> exist, I can't see how it's an "existing feature".

Because you confused functions declared in "math.inc" with built-in 
functions. Your feature request simply suffered from a lack of detail and 
confusion of functionality built-in functions vs ones declared in math.inc). 
There is a native "atan" function. What is - well, was - not there is a 
"atand" function returning degrees. That, similar to asind and acosd needs 
to be added to "math.inc".

So at a minimum, your feature request should have read "There are already 
asind, acosd, atan2d in 'math.inc'. Please add the function 'atand' to 
'math.inc' as well." rather than the rather aggressive question with 
multiple factual errors "There already exist atan, atan2 and atan2d 
functions, why not atand?"

> There was no duplicate request. One request was for metadata inside the
> image metatag parameters. The other request was for scene data overlaid
> on top of the image.

You also need to follow the comments/discussion of the feature requests.

>> Also, please note that you previously made feature requests, but when
>> prompted for what you actually wanted with them, remained silent, such
>> as for feature request #63. It may seem tempting to create one line
>> ideas, but what that really shows is that you have never actually
>> thought about the usefulness of the idea.
>
> That's the only request anyone "prompted" me about as far as I can see.
> Judging by the other replies people seem to have understood the request
> properly.

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.

>> A bit more is required than a single sentence or very short paragraph if
>> you want to start any sort of discussion beyond "I like this" or "I
>> don't like that".
>
> I'm willing to discuss things, but if no one replies other than one-line
> closing message there's not much I can do.

Well, you need to supply more than a one-line feature request then! To get 
more than one-line response to a one-line request would require 
mind-reading, as people would have to guess what ideas are hiding behind 
your request. Usually such speculation leads nowhere, hence it isn't done.

     Thorsten

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.

Sure. And until then there's no reason for its removal from bugtracker.



>> As for setting/overriding metrics, even an HTML coder can override
>> things like x height using things like font-size-adjust and font-stretch.
>
> Yes, it is called "scale" in POV-Ray ;-)

See:

http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/

Scaling based on x height is not as easy as scaling based on font 
height. It requires knowledge of said font metrics.



>> I was talking about sub-topics within extremely long pages. No, the
>> Windows help docs can't help you there as they don't track what topic
>> you're reading at any given moment.
>
> Hmm, I am not sure how a table of contents at the top of such a page (as
> you suggested) would help you keep track of where you are on that page.
> I know that PDF table of content views get updated as you move through
> the document, but I am not aware of any HTML feature (sans JavaScript)
> that could do this interactively.

Sure it would help. All I would have to do is press the Home key to go 
to the top of the page and then click on the sub-heading link. Same as 
if I were visiting Wikipedia or something.



> Please refer to the bug report. What is needed is the version of POV-ray
> you are using, and the error message displayed. The background here is
> (as explained in the comment for that feature request) that the code
> does not have a limit of 20 paths internally, so the problem must be
> coming from some platform specific code that has not been updated. - It
> is correct that there was such a limit in 3.6, but you reported the
> problem against 3.7 beta where it should be exist. That is also my I
> changed the "feature request" to "possible bug".

In this case I went by the docs alone and didn't think to test the 
behavior in the beta first. Sorry.



> No, this syntax will not work. I actually just noticed that i added the
> explanation to report 127 (rather than 128). Among other things, you can
> do things like this:
>
> #declare foo = array[2];
> #declare foo[0] = array[2];
> #declare foo[1] = array[7];
> #declare foo[0][0] = 2;
> #declare foo[1][6] = sphere{1,1}

Very, very ugly. The char count of the above code jumped from 45 chars 
to 135 chars. And, there's now an introduced chance of an undetected 
error occurring if one were to type/change the indices incorrectly that 
povray would never report.



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



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

I originally meant this to be for the simple native CSG objects only, 
not for complex CSG combinations. I.e. spheres, cones and cylinders, as 
well as isosurfaces and parametric objects. Not for intersections or 
other CSG combinations. Basically equivalent to what Moray is capable of 
doing.



>> Pray tell me then why people have taken the time to write these complex
>> macros if there is no benefit? Just this week I've been told at least a
>> half a dozen times that my scenes would render faster if I replaced my
>> objects with meshes.
>
> By whom, and where?

"Shape help" in p.g
"Chris Colefax's Object Bender -- SLOW!!!" in p.a-u
"Spinner" space colony (2)" in p.b.i



>> There are already sind, tand, cosd, tan2d, etc. Why not also tand? Too
>> conspicuous for you?
>
> Well, I see now. You really need to write more than "There already exist
> atan, atan2 and atan2d functions, why not atand?" as a feature request.
> Both "atan" and "atan2" are built in functions. "atand" is not. Now that
> you mentioned the other ones, I had a chance to notice that these
> functions are indeed defined - in "math.inc". That would have been the
> minimum additional necessary information needed to figure out what you
> were up to. Now I know, and indeed have simply added it. So in the next
> beta you should find a
> #declare atand = function (x) {degrees(atan(x))}
> in "math.inc".

Yeah, sorry, I didn't see that it was in "math.inc" either.



-- 
http://isometricland.com

Post a reply to this message

On 6/20/2010 6:07 AM, Thorsten Froehlich wrote:
>> As for font metrics, the request was for getting /and/ setting the
>> values.
>
> Yes, but as was explained there by Christoph Lipka and me, you cannot
> set them in POV-Ray because they are part of the font. What you can do
> though is use a macro for both getting them and modifying a text object
> accordingly. That is pretty much how they are displayed by other
> programs as well. I.e. to change the spacing between characters, in
> POV-Ray you write a macro that takes a string and then creates text
> objects for each character (internally a POV text object is nothing else
> but a collection of character objects) with a different spacing.

Let's discuss this on bugtracker instead. That is the "proper" place is 
it not?



>> The request was for a native "atan" function. Since the function doesn't
>> exist, I can't see how it's an "existing feature".
>
> Because you confused functions declared in "math.inc" with built-in
> functions. Your feature request simply suffered from a lack of detail
> and confusion of functionality built-in functions vs ones declared in
> math.inc). There is a native "atan" function. What is - well, was - not
> there is a "atand" function returning degrees. That, similar to asind
> and acosd needs to be added to "math.inc".

...and this conclusion could as well have been reached via discussion on 
bugtracker instead of here _if_ the topic had remained _open_ instead of 
closed.



>> There was no duplicate request. One request was for metadata inside the
>> image metatag parameters. The other request was for scene data overlaid
>> on top of the image.
>
> You also need to follow the comments/discussion of the feature requests.

What is that supposed to mean? Is it preferable to discuss multiple 
requests in a single entry? Usually people want a separate report for 
each item.



>> That's the only request anyone "prompted" me about as far as I can see.
>> Judging by the other replies people seem to have understood the request
>> properly.
>
> 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'm willing to discuss things, but if no one replies other than one-line
>> closing message there's not much I can do.
>
> Well, you need to supply more than a one-line feature request then! To
> get more than one-line response to a one-line request would require
> mind-reading, as people would have to guess what ideas are hiding behind
> your request. Usually such speculation leads nowhere, hence it isn't done.

I assume people are going to ask if they don't understand something or 
request further comment. And I presume people are going to state their 
conclusions based on a request _prior_ to closing it so that people can 
solicit further comment. There's a "comment" button next to each task, 
after all, near the "close" button maybe.


-- 
http://isometricland.com

Post a reply to this message

On 20.06.10 12:18, SharkD wrote:
> 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.
>
> 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.

> http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/
>
> Scaling based on x height is not as easy as scaling based on font
> height. It requires knowledge of said font metrics.

The link is about aspect ratios when substituting fonts. In effect what is 
describes is just a clever algorithm to scale characters in one font such 
that they take about as much space as another font. You can do the same with 
min_extent and max_extent in POV-Ray, and then scale another font accordingly.

>> No, this syntax will not work. I actually just noticed that i added the
>> explanation to report 127 (rather than 128). Among other things, you can
>> do things like this:
>>
>> #declare foo = array[2];
>> #declare foo[0] = array[2];
>> #declare foo[1] = array[7];
>> #declare foo[0][0] = 2;
>> #declare foo[1][6] = sphere{1,1}
>
> Very, very ugly. The char count of the above code jumped from 45 chars
> to 135 chars. And, there's now an introduced chance of an undetected
> error occurring if one were to type/change the indices incorrectly that
> povray would never report.

It is just an example I had at hand.

>>>>> 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.
>
> I originally meant this to be for the simple native CSG objects only,
> not for complex CSG combinations. I.e. spheres, cones and cylinders, as
> well as isosurfaces and parametric objects. Not for intersections or
> other CSG combinations. Basically equivalent to what Moray is capable of
> doing.

Someone suggested meshes instead of CSG? That is not very sensible at all. 
To speed up CSG obejcts, you should use manual bounding.

>>> Pray tell me then why people have taken the time to write these complex
>>> macros if there is no benefit? Just this week I've been told at least a
>>> half a dozen times that my scenes would render faster if I replaced my
>>> objects with meshes.
>>
>> By whom, and where?
>
> "Shape help" in p.g
> "Chris Colefax's Object Bender -- SLOW!!!" in p.a-u
> "Spinner" space colony (2)" in p.b.i

The object binder macro (I saw that thread, no time to read the others) is a 
rather complex solution to modifying objects in ways that are not really 
possible without, well, changing their mathematical representation. A mesh 
is a workaround for such an object to be modified within POV in a way that 
you would normally modify it in a 3D modeler. Those models usually work with 
meshes and hence make the modifications possible because the triangle meshes 
have certain properties that make non-linear transformation mathematically 
"easy". So the suggestion in that thread more or less is to use a modeler. 
Using the object bender macros on a mesh in POV-Ray would not make it any 
faster.

     Thorsten

Post a reply to this message

On 20.06.10 12:33, SharkD wrote:
> ...and this conclusion could as well have been reached via discussion on
> bugtracker instead of here _if_ the topic had remained _open_ instead of
> closed.

A feature request should be complete in and by itself. A single line is not 
complete.

>>> There was no duplicate request. One request was for metadata inside the
>>> image metatag parameters. The other request was for scene data overlaid
>>> on top of the image.
>>
>> You also need to follow the comments/discussion of the feature requests.
>
> What is that supposed to mean? Is it preferable to discuss multiple
> requests in a single entry? Usually people want a separate report for
> each item.

No, it is not a suggestion to suggest multiple features in one report, but 
if a feature request has resulted in the very same discussion already, no 
summary or conclusion should be made in a new feature request, but instead 
the existing one should be changed. This implies contributing ideas to the 
feature request discussion, and then coming up with a single coherent idea, 
not leaving it at two half-finish ideas.

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

No, the solution was purely SDL based because all the features mentioned 
were SDL primitives that already exist. He just did not supply the SDL itself.

> I assume people are going to ask if they don't understand something or
> request further comment. And I presume people are going to state their
> conclusions based on a request _prior_ to closing it so that people can
> solicit further comment. There's a "comment" button next to each task,
> after all, near the "close" button maybe.

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

Post a reply to this message

SharkD <pos### [at] gmailcom> wrote:
....
> Expandable arrays
> Mixed-type arrays
> Hash arrays
This reminds me of the idea of adding support for an external scripting language
in POV4.
....
> 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.

Stephen S

Post a reply to this message

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