repository
jelle
you are willing to share what is already written?
Personally I think that's preferable to starting from scratch, but
rather go with the more pragmatic approach of integrating code that is
already there. For sure that does not mean accepting all what is out
there, but rather selecting those bits that are well written /
structured and worth elaborating on. This initial commit of code to
the repository is a indexing / reviewing phase of code of different
individuals, forming a base for discussion.
Thomas Bleicher
> To structure python-radiance, is it an interesting idea to commit what
> you are willing to share what is already written?
Oh! Hold the horses!
Although I'm all for reusing already written stuff we should not
happily go ahead and check in everything we have. That's going
to pollute the repository in no time. If we are actually uploading
anything that is not tailored to fit into the p-r package it should
only go in a separate branch (let's call it "dump") from where
bits can be copied/merged into the "trunk" (sorry, don't know
what mercurial calls it yet).
First we need to discuss what the structure of the project should
look like. I was about to rip my projects apart and remove the
bits that are specific to my projects. What's left I will open
up for discussion of the implementation and concepts and if
those are along the lines of r-p and if they are Dave can check
them in.
I think that's a sensible way to consolidate all of our individual
efforts so far.
Thomas
jelle
> happily go ahead and check in everything we have.
> That's going to pollute the repository in no time.
sufficiently coherent / well written / well structured 3) _then_ set
up the repository for development
google code has *great* tools for discussing / debating code, so that
will massively speed up the effort.
I *hate* endless discussion without action, that's all ;)
> If we are actually uploading
> anything that is not tailored to fit into the p-r package it should
> only go in a separate branch (let's call it "dump") from where
> bits can be copied/merged into the "trunk" (sorry, don't know
> what mercurial calls it yet).
> First we need to discuss what the structure of the project should
> look like.
No need to re-invent the wheel.
I'm sure there's solid stuff out there, and yes, I'm curious to see
that.
> I was about to rip my projects apart and remove the
> bits that are specific to my projects.
code...
> I think that's a sensible way to consolidate all of our individual
> efforts so far.
endless, boring design discussions ;)
Here's some ---ancient--- code I wrote a century ago:
http://www.jelleferinga.com/files/python-radiance/ ( right-click save
as... otherwise you get a 500 error... )
the primitives in rad_primitives.py are pretty well written and
perhaps worthy of a commit, perhaps the way of wrapping the radiance
exe's as suggested in rad_prog.py is interesting ( please focus on the
structure, not the implementation, that's seriously untested code ;)
What's cool about rad_primitives is that its trivial to write radiance
file using; just need the tri's and their indices, easy to bind it to
your preferred modeller.
load_hdr.py shows you how to load a .hdr file with the vips module.
-jelle
Thomas Bleicher
> Here's some ---ancient--- code I wrote a century ago:
> http://www.jelleferinga.com/files/python-radiance/ ( right-click save
> as... otherwise you get a 500 error... )
Can't get the *.py files. Only html decorated error messages. Sorry.
Thomas
rocketship
basic functionality of Radiance in a way that is both Pythonic and
familiar to people who have used Radiance via shell commands. It'll
be easier to have people contribute if they are writing towards
something, and we'll end up with documentation.
Severn
Jelle Feringa
> Somebody needs to write an API first - I would start with exposing the
> basic functionality of Radiance in a way that is both Pythonic and
> familiar to people who have used Radiance via shell commands
Got a rough draft of that.
And would be happy to share that, such that we can use this to focus the discussion.
Saw the http://code.google.com/p/python-radiance/ repo, excellent!
Would it be useful to add this?
Also got a nice abstraction of radiance primitives ( materials, polygons, stuff like that ) which makes it easy to implement reading and writing to radiance data from other sources.
Here's an example of how I used this primitive API to export a mesh to radiance format by scripting Rhino from the COM API.
( Uh… this is from years ago… rhino5 will have python programming support ( and yes its cool ;) )
I use this with pythonocc in a similar manner.
from jf.rhino import loadBeta
from radiance.primitives import RadianceMesh # primitive polygon not get confused...
RS = loadBeta.RS; d1= loadBeta.d1; RF.Rsreg(RS)
def rhinoMeshToRadMesh(mshId, identifier, modifier, f=None, triangulate=True):
''' '''
assert RS.IsMesh(mshId)
if RS.MeshQuadCount(mshId) != 0 and triangulate:
print 'mesh has quads...'
mshId = RF.cmdTriangulate(mshId)
mshIndices = map(tuple, RS.MeshFaceVertices(mshId))
mshVerts = map(tuple, RS.MeshVertices(mshId))
# rhino uses 4 coords to encode a cell
# since we've triangulated the mesh anyhow
get_slice = lambda x: x.__getslice__(0,3)
mshIndices = map(get_slice, mshIndices)
mshVerts = map(get_slice, mshVerts)
# ---> these are the radiance primitives
rm = RadianceMesh('jelle', 'zulu')
rm.setIndices(mshIndices)
rm.setVerts(mshVerts)
return rm.write(f)
# ---> done writing radiance geometry...
mshId = RS.GetObject('ugh', 32)
print rhinoMeshToRadMesh(mshId, 'jelle', 'zulu')