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

(The sounds of munching popcorn ensue.)

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

Post a reply to this message

Am 25.06.2010 20:20, schrieb Thorsten Froehlich:

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

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

I prefer to disagree.

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

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

Post a reply to this message

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

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

Post a reply to this message

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

Thank you!


-- 
http://isometricland.com

Post a reply to this message

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

Only the camera and projection pigments are.

Post a reply to this message

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

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

> Subdivision support
Interesting

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

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

Alain

Post a reply to this message

Am 26.06.2010 19:48, schrieb Alain:

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

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

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

Post a reply to this message

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

Post a reply to this message

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

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

Post a reply to this message

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

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

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

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

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

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

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

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

	Thorsten

Post a reply to this message