POV-Ray : Newsgroups : povray.advanced-users : A bunch of feature requests! Server Time
31 Oct 2024 19:16:10 EDT (-0400)
  A bunch of feature requests! (Message 11 to 20 of 69)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Le Forgeron
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 05:36:13
Message: <4c1de10d$1@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 05:45:00
Message: <4c1de31c$1@news.povray.org>
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

From: SharkD
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 05:48:19
Message: <4c1de3e3$1@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 06:07:45
Message: <4c1de871$1@news.povray.org>
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 

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

From: SharkD
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 06:18:32
Message: <4c1deaf8$1@news.povray.org>
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

From: SharkD
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 06:33:55
Message: <4c1dee93$1@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 07:10:14
Message: <4c1df716$1@news.povray.org>
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

From: Thorsten Froehlich
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 07:21:59
Message: <4c1df9d7@news.povray.org>
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

From: StephenS
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 09:25:00
Message: <web.4c1e15d155d1933dfdff507e0@news.povray.org>
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

From: clipka
Subject: Re: A bunch of feature requests!
Date: 20 Jun 2010 10:35:17
Message: <4c1e2725$1@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.