Yuhu! We have a start!!! :)

Thanks so mutch, odf!

I assume you have had a look into the requirements (and differences) related to geometries we are talking about.

We need a class-method to get a simple object from poser (no normals or uv-coodinates yet), but triangulated.

If we have this and a plain camera/light, we can work on the required metrics/transformations before we go further and deal with normals/uv's and more complicated meshes.

I would prefer to do things object-orientated (classes and methods).
Maybe like this:

class PoserGeometry(Object):
    def __init__(self) :
      self.obj = []
      self.normals=[]
      self.uv=[]


    def getGeometry(self):
      return self.triangulateObj(self.obj)
    
    def getNormals(self) :
      return self.triangulateNormals(self.normals)

    def getUV(self):
      return self.triangulateUV(self.uv)

    def triangulateObj(self, data):
      pass

    def triangulateNormals(self, data):
      pass

    def triangulateUV(self, data):
      pass
<br></br><br></br>

 I have to break for some hours. Will be back later.

Quote -
We need a class-method to get a simple object from poser (no normals or uv-coodinates yet), but triangulated.

I'll give it a go. Is a 2d array of point coordinates and another 2d array of point indices for the triangles okay? Plain Python arrays or Numeric?

Oh, before I forget: which Poser version (and consequently, which Python version) are we targeting. I normally use Python 2.4 at work, which I think would require at least Poser 7. Does that sound reasonable, or should I go for 2.2?

 Before I go out - whoever is interested, we need some help for:

exporting light/camera
material export (bagginsbill?)
LUX-Python API
User-Interface (wxPython)
Documentation (better more than one, multilanguage)

Sounds like fun!!
it is interesting that there was a thread on the LUX renderer a few months ago that got sparse attention.
Now that DAZ Studio will have a viable bridge to that FREE renderer there is sudden frantic Demand for a poser bridge.

There is the option of using the FREE version of Daz to open your PZ3, perhaps make some final tweaks, reposing etc. and send that to Lux via the up coming plugin.
attached is a poser scene opened in DS and sent Directly to MODO401 via object export with textures collected by D/S during export.
From poser to completed MODO401 render was about 10 minutes.

I know some find the mere thought of installing DAZ Studio
abhorrent but the option is there and your only cost will be
the price of the plugin just like the D/S users.

lux will work with quads ising the mesh type it does split quads and tris though.

Quote - lux will work with quads ising the mesh type it does split quads and tris though.

Well, I guess I should hit the documentation then before I implement anything stupid.

Quote - lux will work with quads ising the mesh type it does split quads and tris though.

Ups!

My C4D-Exporter makes triangles from quads. So I thought it has to be.

Looking through the Documentation again, I didn't find something. No API-Function to convert quads to triangles, nor a description/example that uses quads.

Under supported  "Shapes/Primitives" I only can find:

Shapes/Primitives

• sphere (full or partial with u/v parameters)
• cylinder (full or partial with angle parameter)
• disk (full or partial with angle parameter)
• cone (full or partial with angle parameter)
• paraboloid (full or partial with angle parameter)
• hyperboloid (full or partial with angle parameter)
• trianglemesh
• heightfield
• loopsubdiv (loop subdivision from base control mesh with arbitrary levels)
• nurbs (Non Uniform B-Splines)
•  
• Can somebody point me to the right place?

Quote - If we could split the work to 3 or 4 people with a "project-manager" (LaurieA?) there is a chance to get something usable within some weeks.

Oh, you're funny ADP ;o).

Laurie

Quote -
In your reply, you mentioned Blender, instead of Daz3D.

It was intentional. The argument that a Python exporter from Poser to Lux is feasible has been based, from several sources, on the fact that Blender's exporters are written in Python and they work just fine.
I know. I added the vertex group supoprt for the OBJ import/export programs of Blender. It is technically possible and it works for the most part but, in my experience, it has scalability problems. My development machine is an 8 core MacPro with plenty of power. When I see an exporter taking a long time exporting a single instance of V4, unclothed, untextured and unmorphed, I know that there is a performance problem. When I release a program to the vast public I feel quite a strong responsibility to make it work in the largest scenario possible. As it stands now, a Python solution doesn't sound as the right answer to me.

Because both Blender and Poser use Python people might be tempted to draw parallels. My comment in the previous message was a suggestion to refrain from doing that. Just because an operation is fast in Blender doesn't mean that it is as fast in Poser. Maybe it is, may it isn't. Until we collect exact data we cannot know.

Quote -
If the former, then I'm curious what is the issue with Poser's data structures. I find it particularly straightforward to read its materials in Python. Or are you talking about geometry? Because it seems to me the greatest benefit (and effort to build) in Reality was the material conversion.

See above. My issue is that I believe that Blender is one very optimized piece of software. You might not like it but it's coded for speed. I would not write a Lux exporter in Python for Blender if the complexity of scenes that I have to deal with are the typical scenes used in Poser of Daz Studio. Even with the very fast Python interpreter. I know that LuxBlend is written in Python and I believe that it would have some performance problems in dealing with, let's say, Stonemason's Streets of Asia plus a couple of clothed V4s/M4s. Scene like that generate a very, very large dataset. Yes, machines will be faster but ... a) I want my program to work for people who are not on the bleeding edge of technology and b) a C++ implementation will go even faster.

Quote -

Quote - The level of detail of Poser's figures is also much higher than anything that I've seen exported from Blender to Lux.

I don't understand this. You used V4, right? Poser uses V4 as well - probably more than half of all Poser use is with V4, just like Daz3D. Why is V4 exported from Poser going to be more complicated than from Daz3D or from Blender?

What I meant was again in reference to the fact that several people pointed to LuxBlend as a proof of fact. All the scenes that I see that were exported from Blender with LuxBlend were not that complex in terms of detail. Exactly because I know that Poser scenes are similar to Studio's scene I know that the demands on the exporter will be much heavier than whatever has been tested on LuxBlend. And if somebody from the LuxRender developers is reading this let me be totally clear that I'm in awe at what LuxBlend does. It's a very complex piece of code that has very, very clever solutions to a lot of problems and is doing some little miracles both in the UI and in the computation. It's been an invaluable source of help in writing Reality. I just don't believe that, at this time, it is suited for the workflow of Studio or Poser users. 

I hope this is clarifying my position.

Quote -
Oh, you're funny ADP ;o).

Yes I know.

:)

But - why not? Someone has to coordinate things. At least between the programers and the doc-writers (if someone wants to do this job). And, most important: If you leave programers alone you usually will get a piece of complicated science :)

This is only a small project. But we can test if bigger things are possible without one person has to spend a big part of his life. If things are splitted into small pieces, someone has to hold anything together.

As someone said before, methods/function written in Python may be easyly replaced with a call to C-Code (DLL, because ctypes seams to work with P7/8) if anything works.
Calling Posers-API to get geometry-data is still required.  Having this data in a fast numeric-array (Python) is a good start-position.

 Thanks, ADP, that sounds good. Here's a snippet that will get and triangulate Poser geometry:

   for actor in scene.Actors():
                if ((actor.IsBodyPart() == 0) & (actor.IsProp() == 0)):
                        continue
                if (actor.Visible() == 0):
                        continue
                geom = actor.Geometry()
                if (geom == None):
                        continue
                if (geom.WorldVertices() == None):
                   continue
                file.writelines(['AttributeBeginn'])
                file.write('Shape "mesh"n')
                verts = geom.WorldVertices()
                if (verts != None):
                        file.write(' "point P" [n')
                        for vert in verts:
                                file.writelines ([fpformat.fix(vert.X(), 8) , " ", fpformat.fix(vert.Y(),8), " ",fpformat.fix(vert.Z(),8),"n"]) 
                        file.write("]n")
                else:
                        print "no verts"
                polys = geom.Polygons()
                sets = geom.Sets()
                if (polys != None):
                        file.write(' "integer triindices" [n')
                        for poly in polys:
                                start = poly.Start()
                                for v in range(poly.NumVertices() - 2):
                                        file.writelines([str(sets[start])," ", str(sets[v+start+1]), " ", str(sets[v+start+2]), "n"])
                        file.write("]n")
                file.write("AttributeEndn")

This is only a triangulation of convex polygons - concaves need some extra work. Here's how to get a file dialog in P8/Pro2010: man = poser.WxAuiManager() root = man.GetManagedWindow() dialog = wx.FileDialog ( root, message = 'Export...', wildcard = '*.lxs', style = wx.FD_SAVE )

res = dialog.ShowModal()
if (res == wx.ID_OK):
        ExportRender(dialog.GetPath())
dialog.Destroy()

Quote - > Quote -

Oh, you're funny ADP ;o).

Yes I know.

:)

But - why not? Someone has to coordinate things. At least between the programers and the doc-writers (if someone wants to do this job). And, most important: If you leave programers alone you usually will get a piece of complicated science :)

This is only a small project. But we can test if bigger things are possible without one person has to spend a big part of his life. If things are splitted into small pieces, someone has to hold anything together.

Because, while I've coordinated lots and lots of graphic design projects, I know absolutely zilch about programming and how programs run. I don't have a shred of knowledge about what should be done first, who even would be working on what part of the program, even if I know (for the sake of an example) odf was working on mesh export, bagginsbill on material conversion, etc....I don't have any idea where each piece of coding lies in the whole scheme of things. I think a program manager should at least know a little about what they're managing...lmao. Not that I mind at all, it's just I don't think I'm really the right person to do it ;o).

Laurie

I think ADP effectively voted himself leader of the coding team, and Laurie is our on-site customer and marketing director. As such, I would like to repeat my earlier question to her: which version of Poser should we target?

To ADP, I suggest considering code sharing strategies for the team that are more useful than posting files in this thread. I am personally quite fond of github, but of course there are many other options.

If you like, we can set up a private forum at the Peanut Gallery for you boys to talk back and forth ;o). It's just an idea. It's nice and quiet there...lmao.

I think targeting the latest versions of Poser would probably be best. Possibly 7, but I wouldn't go lower than that. Of course, if those versions can handle it, well then....

Laurie

Quote -
It's Open-Source, so get coding!!    That's what Open-Source is supposed to be all about...

no, it's not.  open source is about enabling people who would like and are able to contribute to do so.  i have zero experience or skill making stand-alone apps (though i'm sure i could learn), and i'm not particularly interested in Kerkythea.

if i had nothing else to do, i'd probably contribute to Blender.  but i have tons else to do, so i probably never will.  unless i get some sort of add-on to my brain that makes me wildly more productive and suddenly a programming wizard. edited to add: this would be the bagginsbill wetware plug-in, and i'd definitely pay for that.

sounds like a Poser plug-in project is actually emerging out of this.   is there anything besides programming that would help you guys?

I would be happy to give some help for this project too :)
I know nothing in programming or python coding, but ADP talked about a multilanguage documentation and i could make a french translation if needed :) though i guess there's a lot of work to do before to be in the documentation process ;)

Very nice to see many people want to help.

@odf: Sorry, I'm surely not the right person for this role (not at last because I have to much problems with the language). But how about you?

For the discussion about this project I think the programmers should go over to the Python-Forum. Probably other people here are interested to have an eye on this or some sub-solutions.

@kobaltkween,
@vincebagna: This project needs people with know-how about Lux (from the point of an Poser user). No sience or theory, but practice, e.g. time consuming experiments.  People with this know how are able to give hints to the programmers and the userinterface-makers. Beside of a user-documentation from someone knowing and not guessing. And yes, its probably needed to use something other then Poser in the first run, just to have something to start and, later, compare with.

Quote - Here's a snippet that will get and triangulate Poser geometry:

Many thanks for this. I'm sure odf can use it.

Quote - For the discussion about this project I think the programmers should go over to the Python-Forum. Probably other people here are interested to have an eye on this or some sub-solutions.

Well, if the programmers and helpers involved would like a private forum to discuss things and you think you'd like that (without others jumping in), shoot me an email and I'll set something up for you guys. Since we have forums already established, it's just a matter of creating the forum and adding the interested parties access ;o). I can definitely help in that regard...lol.

Let me know.

Laurie

ok.  so how about this?  right now i'm trying to get a leather catsuit made, and i'm in the final stretch (testing colors now, finishing off files next).  so let me get that done first.  then i could find a photo i like, and make a simple scene in Blender (no people yet), and try to get it into Lux.  sound like a good start?

Quote - > Quote - Here's a snippet that will get and triangulate Poser geometry:

Many thanks for this. I'm sure odf can use it.

Oh, definitely! Hunting through the API docs to figure out how to get data in and out of Poser is very tiresome. I'm sure though that there's a very good reason why there's still no fully linked HTML version like for every other API on the planet. :laugh:

ADP: Sorry, but I am not taking on any new projects at this time. If that language thing worries you, maybe I could be your translator. But I think you'd be doing just fine.

Quote -
Oh, definitely! Hunting through the API docs to figure out how to get data in and out of Poser is very tiresome. I'm sure though that there's a very good reason why there's still no fully linked HTML version like for every other API on the planet. :laugh:

I made a script to output your own HTML-doc for the Poser API. Easier to use than a PDF. You can download it here: www.poserprofis.de/python/ADPcreatePP-Docu.zip
Start the script from within Poser. 

Quote -
ADP: Sorry, but I am not taking on any new projects at this time. If that language thing worries you, maybe I could be your translator. But I think you'd be doing just fine.

I also have not so mutch time to spend. But ok, I'll try to do it until somebody takes it over. 

Didn't think GIT is the right thing for this project. To mutch to learn for people not familar with things like GIT. Python source is small enough to send it via email. The maintainer (I guess me for now) can collect and check the source-snippets (classes/methods) and put the whole thing on a website free to download for everyone (maybe to create some exiting additions).  Same for the user-interface (nobody out there interested to create one?) and the documentation.

Quote -
Well, if the programmers and helpers involved would like a private forum to discuss things and you think you'd like that (without others jumping in), shoot me an email and I'll set something up for you guys.

Well, I guess Stewer, ADP and I could just use German if we needed some privacy. :lol:

I did some first experiments with LuxRender 0.7 in the meantime. I've managed to produce a scene file by hand and render it through the Lux GUI. I've also made some progress understanding the Python API, but so far haven't actually gotten a render out that way.

Anyway, I found that quadrangles worked just fine, as do - supposedly - meshes with a mix of tris and quads. So unless someone has a good reason to do everything in triangles, I would suggest to only triangulate pentagons and higher for export and leave the triangles and quadrangles as they are in Poser.

Quote - Ok, maybe this is not quite relevant at this state of the development, but this is a fast test on some shading for humans on Lux, by now I know some translucent effect can be done mixing materials, look at the body texture of Posette, I'm not sure it looks realistic but it can be done.
And something that may be considered specially for BB that is on the materials: the transmaps must be inverted, white is transparent, black is solid, I don't know if it can be solved someway in the code, not in Luxblend.

As I checked the sourcecode for the C4D-Lux-Exporter, I saw all maps are "manipulated". Gamma corrected, changes to the transmaps. Just while changing parameters, not touching the images.

In the Lux-Forum I heard the programmers are working on a SSS-Solution. And I saw a (fast) SSS-fake based on translution somewhere. So yes, it should be possible to render good skin if all possibilities are explored (at least if textures are used without highlights and shadows burned-in).

The ability to mix materials is really nice. Probably you want to document your experiments in a thread named "Poser needs Lux: Materials" (or something like this)?

Quote -
I made a script to output your own HTML-doc for the Poser API. Easier to use than a PDF. You can download it here: www.poserprofis.de/python/ADPcreatePP-Docu.zip
Start the script from within Poser.

Now that's what I call a useful script. Many thanks!

Quote -
Didn't think GIT is the right thing for this project.

Fair enough! You do the work, you make the rules.

I very much encourage everyone who thinks of him- or herself as a serious programmer to learn git or at least mercurial, though.

From my little experience about Lux, I found about the geometry file, at least as was exported by Blender:

1- The scene geometry is grouped by groups or actors or props or objects.
2- Each group is subdivided by material.
3- Within each material comes in the following order.
   - Face indexes (triangles)
  - List of vertices x,y,z
 - List of texture coordinates  u,v

So, an lxo file looks as:
Group
 Material
   Triangles
   Vertices
   uv
Material
  Triangles
  Vertices
  uv
....
...
Group
  Material
.....
....

Group
  ....
  ....

Consideration
1-  The mesh is divided into triangles, but I think that can be used quads too because existe the quad entity.
2- Within each material the vertex index starts from zero
3- Each material has its own vertices, there do not exist vertices shared by other material or groups, so the mesh is cut and unwelded at material boudering that can cause a wrong illumination.
4- I think that this can be solved including a list of normals for each vertex within a material.
5- The texturing is done by vertex, this can create problems in closed surfaces. A texture coordinate at a seam point has only one texture uv and not two or more for each seam side.
This problem never happens with obj and Poser because each face can have its own uv for each vvertex of the face.
6- Probably this problen can be solved adding some extra uv coordinates as Lightwave does.

Here is a short and fast test if a geometry (actor/prop) needs more than just one material:

geom=actor.Geometry()
polys=geom.Polygons()
if [p for p in polys if p.MaterialIndex() != polys[0].MaterialIndex()]  :
    print "more than one material in this geometry found"

A first test says that writing the triangulated geometry data for a hires Antonia needs less than 1 second.
This test does not include splitting by material and no UV-data has been written.
Tested with Windows in a virtual machine owning 2 Processors (host is Linux), 2 Gig RAM, virtual Filesystem.

Quote - Here is a short and fast test if a geometry (actor/prop) needs more than just one material:

geom=actor.Geometry()
polys=geom.Polygons()
if [p for p in polys if p.MaterialIndex() != polys[0].MaterialIndex()]  :
    print "more than one material in this geometry found"

Simpler would be to use geom.NumMaterials() > 1 as the test, no need to iterate over the polygons.

I found out that often a lot of materials are defined but not used by an actor. 
Antonia for example has a "brow" material with the hip :)

In that case it would be sensible to fold the material counting into the code that splits the mesh by material.

Quote - I found out that often a lot of materials are defined but not used by an actor. 
Antonia for example has a "brow" material with the hip :)

Yep! Since the drop-down menu in the material room lists materials in the order they are found, Antonia's obj file contains a list of dummy "usemtl" statements before the first group.

Based on Kawecki's findings, I think we will need to split vertices at seams as well as material boundaries and provide normals at least for those split vertices in order to avoid shading artifacts. My hope would be that we can get those normals from Poser and don't need to recompute them on the fly.

So far, this seems entirely doable. Too bad I have to code web sites seven hours a day, or I would get onto it right this minute.

The most serious problem that found is to find where are the seams of the same material.

Quote - The most serious problem that found is to find where are the seams of the same material.

I agree, but that's not too bad, either. One has to find out where polygons share edges and then compare the uv indices on both sides. That could be a big performance hit if done "on foot", but Python has these nice, very fast built-in hash tables, so it shouldn't be too much of a problem.

Another thing to be careful is about repeated material names, the same name but different figure or prop.

Quote - Another thing to be careful is about repeated material names, the same name but different figure or prop.

Yes, but I think that shouldn't be a problem if we generate the output on a by-actor or by by-figure-or-prop basis.

Maybe I'm misunderstanding the Lux documentation, though. Is it actually possible to create named materials and use them later. From what I saw it seemed like one always had to include the material definition directly into the attribute block (possibly using include, which would mean one file per material). I haven't read very much yet, though, so I may be missing things.

I have significant experience programming in GML, a scripting language based around a delphi core. Way back when I did some of the leading modification research into the game "Severance Blade of Darkness" a game written primarily in Python, whith a C core.
Most recently I been programming extremely complicated modifications for Operation Flashpoint : Dragon Rising (to the point that Codemasters tried to hire me) which use LUA 5.2 with a C core.

I would abolutely love to help with this, however I never tried to program anything for poser passed a script which clears all materials on an object, and a GI script for P7.

If someone can give me some good links to python-in-poser refernce manuals (like the LUA bible type thing) and what has yet to be figured out and coded, I'll start working on it

Quoting ADP:

Quote -
I made a script to output your own HTML-doc for the Poser API. Easier to use than a PDF. You can download it here: www.poserprofis.de/python/ADPcreatePP-Docu.zip
Start the script from within Poser. 

I think that plus the PDF file that comes with Poser should get you started. I need to get my head wrapped around the Poser API as well, so maybe we can be study-buddies of sorts.

Quote - Maybe I'm misunderstanding the Lux documentation, though. Is it actually possible to create named materials and use them later. From what I saw it seemed like one always had to include the material definition directly into the attribute block (possibly using include, which would mean one file per material).

In the geometry file (lxo)

    NamedMaterial "mat2"
    Shape "trianglemesh" "integer indices" [
..... geometry here ....
...................... ]
    NamedMaterial "floor"
    Shape "trianglemesh" "integer indices" [
..... geometry here ....
...................... ]

In the material file (lxm)

    # Material 'mat2'
Texture "mat2::Kd" "color" "imagemap"
   "string wrap" ["repeat"]
   "string filename" ["building60.jpg"]
   "float gamma" [1.000000]
   "float gain" [1.000000]
   "string filtertype" ["bilinear"]
   "string mapping" ["uv"]
   "float uscale" [1.000000]
   "float vscale" [-1.000000]
   "float udelta" [0.000000]
   "float vdelta" [-0.000000]
Texture "mat2::Kd.scale" "color" "scale" "texture tex1" ["mat2::Kd"] "color tex2" [1.00000 1.00000 1.00000]
MakeNamedMaterial "mat2"
   "string type" ["glossy"] "texture Kd" ["mat2::Kd.scale"]
   "color Ks" [0.005396 0.005396 0.005396] "float index" [0.0] "float uroughness" [0.250000] "float vroughness" [0.250000]

    # Material 'floor'
Texture "floor::Kd" "color" "imagemap"
   "string wrap" ["repeat"]
   "string filename" ["floor240.jpg"]
   "float gamma" [1.000000]
   "float gain" [1.000000]
   "string filtertype" ["bilinear"]
   "string mapping" ["uv"]
   "float uscale" [1.000000]
   "float vscale" [-1.000000]
   "float udelta" [0.000000]
   "float vdelta" [-0.000000]
Texture "floor::Kd.scale" "color" "scale" "texture tex1" ["floor::Kd"] "color tex2" [1.00000 1.00000 1.00000]
MakeNamedMaterial "floor"
   "string type" ["glossy"] "texture Kd" ["floor::Kd.scale"]
   "color Ks" [0.010398 0.010398 0.010398] "float index" [0.0] "float uroughness" [0.250000] "float vroughness" [0.250000]
........

Ah, thanks! NamedMaterial and MakeNamedMaterial are not described in the scene file documentation, just used in examples. Those are definitely good to have; and as you said, names must be chosen carefully.

I think that is similar to 3dsMax, where geometry and materials are defined separately, then geometries makes reference to the material library.

If two props use the same material name then the two props will have the same color, texture, etc.
Beware of "Preview" name, all boxes, cylinders, spheres, torus will look the same!

I think the geometry-exporter should get the materialname to use as a parameter.

There are some other problems to resolve regarding to materials. I think the best idea will be to have a seperate (user-defined) node in a Poser material with hints for Lux-Materials - and a name to use.

Because we need a wacro for this, this wacro is able to make sure we have unique names for a scene.

Another advantage is that we can create special Lux materials, point to this materials from within Poser and adjust parameters via Posers Materialroom.

The scene-collector part of the exporter can check if Lux materials are defined and, if not, can try to make a best guess. So the geometry-part can be sure to get unique materialnames (and if a materialname is not unique, this is what the user wants).

What do you think?

Well, if an example helps, right now I'm working on a project that has walls, molding, etc. While each wall mesh is separate and has a different name, the wall material on each mesh is called wall, the baseboard material is called baseboard and so on. Even though they have the same names, they do NOT use the same texture map.

Laurie

I don't understand. Why not just prefix the material name with the name of the figure or prop it is in? What is the problem you are trying to solve here?

Quote - I don't understand. Why not just prefix the material name with the name of the figure or prop it is in? What is the problem you are trying to solve here?

I would like to part things. Object orientation may help to keep things easy. So a geometry exporter should do not more than export a geometry. Solving the material problem is another part.

Having things seperated may help to add extensions later. 

Object: Put some things in (materialname and a pointer to a Poser geometry here), pull the trigger and get someting out (converted geometry ready to use with Lux).

Advantage: If the material-strategy is changed later, the geometry exporter will work as before.

This is the point where the language barriere stops me :(

Quote -
Object: Put some things in (materialname and a pointer to a Poser geometry here), pull the trigger and get someting out (converted geometry ready to use with Lux).

Ah, I see. I was going to suggest that the class or method responsible for exporting the geometry receives an argument "materialHandler" which would respond to a method "emitMaterial". For testing, I would use a very simple materialHandler object, later to be replaced by the real thing.

Another question that occurred to me is how to emit the Lux instructions. There are at least two modi: write to a file or call the Python API. At some later point, we might want to build up an internal data structure that can be manipulated in place before it is passed on to Lux. So I guess it would be good to define an interface for that as well, and pass an emitter object around to which all the output tasks are delegated.

Sound good so far?