 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Are you interested in contributions of code cleanup like improving
const-correctness, or C++ifying (putting into real classes) textures, etc.
in the same way primitives are?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Are you interested in contributions of code cleanup like improving
> const-correctness, or C++ifying (putting into real classes) textures, etc.
> in the same way primitives are?
>
Not for 3.7, there are too many bugs still to fix! -- I you are looking for
a holiday season activity: Someone taking a look at radiosity would be
really appreciated... ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Not for 3.7, there are too many bugs still to fix! -- I you are looking
> for a holiday season activity: Someone taking a look at radiosity would be
> really appreciated... ;-)
I doubt I'd understand *any* of the maths involved :)
(I've yet to solve t out of vlength(center - start+direction*t) = radius,
what are my chances with radiosity?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> I doubt I'd understand *any* of the maths involved :)
>
> (I've yet to solve t out of vlength(center - start+direction*t) = radius,
> what are my chances with radiosity?)
The issue isn't likely to be with the maths per se; that is written and working.
The problem is more to get it working properly with the multi-threading. This
involves two main thrusts: firstly, to get it running in parallel efficiently
(the pre-trace is a major problem here), and, secondly, to avoid the need to do
new samples during the actual render, since apart from problems with animations
(different render sequences of sub-blocks could lead to slightly different
lighting), we'd also have the nasty issue of efficient thread-safe access to the
tree holding the sample information ('efficient' being the key issue).
Christoph has done some investigation into this and we think we have a means of
avoid the run-time sampling, though due to man-power issues we've not gone into
radiosity much (and really we need to get other stuff working properly first).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> (and really we need to get other stuff
> working properly first).
Like what? I don't see a public to-do list :)
"Known issues" in the release notes isn't enough, it has quite broad items.
We need a list of even very minor things that need fixing.
A suggestion I've seen in a blog: if an item on the to-do list can be in any
state other than "done" or "not done", for example "70% done", you haven't
split them enough. I think that's a bit extreme, but still an interesting
idea.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 01 Dec 2008 10:47:20 -0200, Nicolas Alvarez <nic### [at] gmail com>
wrote:
>
>A suggestion I've seen in a blog: if an item on the to-do list can be in any
>state other than "done" or "not done", for example "70% done", you haven't
>split them enough. I think that's a bit extreme, but still an interesting
>idea.
Interesting if you want to spend your time writing "to do" lists. Not very Real
World in my experience.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Are you interested in contributions of code cleanup like improving
> const-correctness
Attached a patch removing some const_casts in the pattern parsing (I saw no
reason for Parse_Blend_List to take a non-const BLEND_MAP*).
Post a reply to this message
Attachments:
Download 'us-ascii' (4 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 01.12.2008 13:47, Nicolas Alvarez nous fit lire :
> We need a list of even very minor things that need fixing.
>
Have you read posts title "Quick summary *" ?
That's what I tried to do, just in case someone would have some spare
time and an insight of the code.
Ok, it was not minor things, only what I would see as release-blocking
issues.
The one for C++ people would be to check the difference in execution for
isosurface when bounding box get activated, as it provides a different
rendering of contain_by sphere.
On the multi-thread with bounding box on, the two-tones lightning of
contain_by box is also an issue.
It's not such isosurface than bounding box tree with container of
isosurface.
And one for X11 people for unix port, there is something fishy about the
creation of the rendering window: it happens to randomly lock for a
mouse event if used locally (on remote X11 with Xming, it just lock
dead). An advanced knowledge of the used toolkit would help to get the
right sequence of function's calls (with appropriate locks too, if needed)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
