 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmail com> 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.
>
> 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
|
|
| |
| |
|
|
|
|
| |
