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