 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomore hotmailcom> wrote:
>
> We need people to work on the Moray codebase. I remember a call several years
> ago for people to do code cleanup and rip out the proprietary and
> platform-dependent stuff.
>
> I would help if there was anything I could do, but my programming skills need a
> lot of work.
>
> I have done some interface design in Qt Widgets, and I've been thinking about
> exploring JUCE Toolkit. Both would be good options for the project.
>
> I'd be willing to discuss if anyone thinks I could be of use.
>
> Regards,
> A.D.B.
Help the Povray developers. It will be better for all of us.
Writes clipka: "It isn't enough of us". Go to them.
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> My dear developers!
> You do a lot of work.
> I see it.
> Your mistake - isn't present a fast render of curves.
> Sphere_sweep - bad option.
> Povray - is very good. But, you are stubborn. :)
> Why you aren't interested time of a render
> scenes, but only quality???
> Quality - it is very good, but speed is your prize.
> You don't understand it - it is bad.
> I don't advise. I recommend to strengthen your force.
> You are strong!
> Give us what isn't present anywhere!
>
> Sorry, if you haven't understood me again :) :(
>
>
Over time, there have been several speed improvement for several
features. For example, focal blur, on the exact same computer, is
significaly faster now than using version 3.6.
POV-Ray also got faster for some other features over time. Also, the
hardware performance increased exponentialy.
BUT... We still have scenes that take just as long to render as they did
in 1980.
As computer's power increased, and new features are introduced and
improved, artists made more complex and demanding scenes, and also
rendered at larger resolution and beter antialiasing settings.
The use of advanced features, once rarely used, became common place. In
the 90's, radiosity and area_light where seldom used.
We commonly use media to make clouds while there was a time where all
clouds where made using sky_sphere and, some times, planes using mostly
transparent pigments.
Give peoples super computer 1000 times faster than today's computers,
and they will make scenes that will take the same time to render, and
even more, as they demand at least 1000 more computation.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/28/2016 5:42 AM, Jaime Vives Piqueres wrote:
>> Merkin? What is it? the Dictionary doesn't yield result. :)
>
> Just do a search on Google images... :)
Ah. Lap tribbles.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/28/2016 12:53 PM, Anthony D. Baye wrote:
> We need people to work on the Moray codebase.
I have no interest in Moray, but what I'm looking to work on (other than
my own pov-programs)
1) povray - Debug stream on windows wraps at 80 chars, even writing to a
file. Unix doesn't do this. This should be an easy fix and get my feet
wet in the povray code base.
2) povray - Memory leaks. Povwin leaks like a sieve. My workflow has
changed to, every time before I render a couple hundred frames, I exit
and restart pov to get back memory. povwin can grow to 4GB easily. I'm
hoping to find a tool that makes this jump out easily. It looks like the
built in profile tools in vs15 may do this.
3) povclipse - I understand that it doesn't work with 3.7. I couldn't
use it as is anyway without a dynamic preview window. I want to add
that. (The number of times in povwin I have Shift-clicked a label
expecting to go to the definition; or highlight a token expecting it to
highlight that token everywhere.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dick balaska <dic### [at] buckosoftcom> wrote:
> On 2/28/2016 12:53 PM, Anthony D. Baye wrote:
>
> > We need people to work on the Moray codebase.
>
> I have no interest in Moray, but what I'm looking to work on (other than
> my own pov-programs)
>
> 1) povray - Debug stream on windows wraps at 80 chars, even writing to a
> file. Unix doesn't do this. This should be an easy fix and get my feet
> wet in the povray code base.
>
> 2) povray - Memory leaks. Povwin leaks like a sieve. My workflow has
> changed to, every time before I render a couple hundred frames, I exit
> and restart pov to get back memory. povwin can grow to 4GB easily. I'm
> hoping to find a tool that makes this jump out easily. It looks like the
> built in profile tools in vs15 may do this.
>
> 3) povclipse - I understand that it doesn't work with 3.7. I couldn't
> use it as is anyway without a dynamic preview window. I want to add
> that. (The number of times in povwin I have Shift-clicked a label
> expecting to go to the definition; or highlight a token expecting it to
> highlight that token everywhere.
I've thought that it would be nice to have a curses interface for the console
render stream. It would be a great addition for people who run console-only
renderfarms, especially if we manage to get the distributed rendering system.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/28/2016 5:38 PM, Anthony D. Baye wrote:
> I've thought that it would be nice to have a curses interface for the console
> render stream. It would be a great addition for people who run console-only
> renderfarms, especially if we manage to get the distributed rendering system.
Can you describe this a little bit?
I use sockets and a web interface for my "console-only" renderfarm.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dick balaska <dic### [at] buckosoftcom> wrote:
> On 2/28/2016 5:38 PM, Anthony D. Baye wrote:
>
> > I've thought that it would be nice to have a curses interface for the console
> > render stream. It would be a great addition for people who run console-only
> > renderfarms, especially if we manage to get the distributed rendering system.
>
> Can you describe this a little bit?
>
> I use sockets and a web interface for my "console-only" renderfarm.
It's not a means of communication. Curses (NCurses or pdCurses for free
versions) is a library for creating interactive text-only interfaces in a
console environment. It would allow the console output to be split into
different panes, similar to what you see in the bios screen or the old dos
shell.
So you could have the output stream in one pane, and a progress display in
another pane, and interactive options for pausing or stopping a render, you
could even keep a terminal running in a separate pane without resorting to a new
tab (especailly useful if you're running your farm in tty mode, although I
suppose you could jump between tty1 and tty2).
Of course, a web interface is good too.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/28/2016 7:16 PM, Anthony D. Baye wrote:
> It's not a means of communication. Curses (NCurses or pdCurses for free
> versions) is a library for creating interactive text-only interfaces in a
> console environment.
Sure, I wrote a curses space invaders on the pdp-8 in the 80s, and...
on a $4000 B&W Xterminal, swiss banks would display a terminal window
with curses forms. :)
> It would allow the console output to be split into
> different panes, similar to what you see in the bios screen or the old dos
> shell.
>
> So you could have the output stream in one pane, and a progress display in
> another pane, and interactive options for pausing or stopping a render, you
> could even keep a terminal running in a separate pane without resorting to a new
> tab (especailly useful if you're running your farm in tty mode, although I
> suppose you could jump between tty1 and tty2).
>
> Of course, a web interface is good too.
Ok. What I was thinking was adding a talker socket to povray, which
would then connect to povclipse. With a decent protocol, it *could*
connect to a curses program too. That keeps as much non-raytrace foo as
possible out of povray.
There is definite value in adding a pause button.
I'm not sure what you mean by "output stream". It's text, you *could*
just read the output file(s).
>
> Regards,
> A.D.B.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey, wait - you work with laser cutters? Where are you located? And what
materials can you cut with these laser cutters? I might have a need for
some parts, maybe, in a few weeks. Starting to talk about that would
make it possible for me to make some decisions.
On 28.02.2016 08:08, Bald Eagle wrote:
> I'm currently working with laser cutters, and so I'm doing the same with SVG.
> I'd rather have DXF output - but jeez, what a crappy format :O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wished it would be SOMEHOW (don't ask me how) be possible to strike a
deal with some universities and have as part of that many young student
programmers working on the POV-Ray code in addition to the existing
developers, for further improvements and new features where applicable
and/or possible. 10,000 eyes and hands can do more, than just 100 eyes
and hands. Maybe, some universities would be even interested, since
POV-Ray is open-source and a good challenge for new developers with
their new ideas. Just, someone need to get some universities interested.
This is just a thought of mine, but I admit that I know it might be an
impossible idea. :-)
On 28.02.2016 15:25, Alain wrote:
>> My dear developers!
>> You do a lot of work.
>> I see it.
>> Your mistake - isn't present a fast render of curves.
>> Sphere_sweep - bad option.
>> Povray - is very good. But, you are stubborn. :)
>> Why you aren't interested time of a render
>> scenes, but only quality???
>> Quality - it is very good, but speed is your prize.
>> You don't understand it - it is bad.
>> I don't advise. I recommend to strengthen your force.
>> You are strong!
>> Give us what isn't present anywhere!
>>
>> Sorry, if you haven't understood me again :) :(
>>
>>
>
> Over time, there have been several speed improvement for several
> features. For example, focal blur, on the exact same computer, is
> significaly faster now than using version 3.6.
>
> POV-Ray also got faster for some other features over time. Also, the
> hardware performance increased exponentialy.
>
> BUT... We still have scenes that take just as long to render as they did
> in 1980.
>
> As computer's power increased, and new features are introduced and
> improved, artists made more complex and demanding scenes, and also
> rendered at larger resolution and beter antialiasing settings.
>
> The use of advanced features, once rarely used, became common place. In
> the 90's, radiosity and area_light where seldom used.
>
> We commonly use media to make clouds while there was a time where all
> clouds where made using sky_sphere and, some times, planes using mostly
> transparent pigments.
>
> Give peoples super computer 1000 times faster than today's computers,
> and they will make scenes that will take the same time to render, and
> even more, as they demand at least 1000 more computation.
>
>
>
>
> Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
