Hi! I've created this topic to discuss about the future of Pixie.
In first place I think we must offer our help to Okan, sending a message asking to join the Sourceforge project.
Obviously is much more easy continue the Okan's job and not opening a new project making a Folk.
I think we must continuing sending Bugs and Patches even if no are closed, to future reference. I'm not an exceptional developer, and I've created a section to try to explain and learn about the source code on Wiki: http://www.renderpixie.com/pixiewiki/Documentation/Source_code_in_deep
Please, if somebody can contribute with it, will be very helpful for less skilled developers.
I've sent a message to Koan requiring add me to the project team, I'll notify here their decision, or if I have not answer.
I'll second that, I love Pixie ;-), but that'd be great to have a road map and more contributors. There are some missing features I'm interested in (trimmed patches, CSG…), could even try to contribute, but as of its current state, it seems awkward to propose new things (speaking of either feature requests and/or code patches).
Also, newer hosting sites (bitbucket / github) seem to provide a much better environment for collaboration. Okan, would you be interested in moving to one of those?
Yes, it'll be great to have a SVN/CVS branch with more contributors, I've some new features/ bug fixes to merge into the source code, if Okan agree of course.
I began a ptc filter to compute SSS with the pointcloud technology, and I'd like other contributors look at it to make it better and faster.
I think it should be interesting to include some regression tests too will well written RIBs ans SLs files.
Don't want to see this project die too !
This is just fantastic :) Saw that you were added as project memeber by Okan aswell, wish you all the best in the revival effort!
I think Pixie is great, but some of the code is very difficult to
understand. I found a bug (which Okan fixed very quickly, thanks!)
and the patch was to change +=3 to +=6 in one of the macros in
shaderFunctions.h. Even after the fix was made I had no idea how it
helped or what the flow of control was.
Any time a program has to support a separate programming language
debugging is going to be difficult. For that reason, if people want
to take over or supplement support of Pixie, I would suggest
thoroughly documenting (or rewriting) all of the macros in
shaderFunctions.h and shaderOpcodes.h.
Hi! Thank you for the good wishes :)
At a first step I'll continue studing the code, and documenting it.
At same time I'll make a new branch on SVN and try to add some patches and in a third stance take a look to the bugs.
The first modification on code will be the Doxygenfication of the comments.
Remember to check the "Source in deep" section on the wiki, and if you can, helping with code documentation.
and thank you for your support :)
Thank you Kevin for the suggest, for now I'll not made big changes, while I don't understand deeply the source code. I'll work on document all the Pixie render pipeline.
I've created a branch! :)
You can download and try it on:
svn co https://pixie.svn.sourceforge.net/svnroot/pixie/branches/eibriel pixie-branch
Slowly I'll apply the patches, and take a look on the bugs.
If anyone has submitted a patch for an old SVN version, and it is not applied, please resubmit it for the actual version. Add a RIB file to visualize the results, and an image or description about the old and new Pixie behaviour.
If you are not the patch maker, but you could successfully apply it to the actual version, can do the same ;)
I've used Pixie since it was first posted here on SourceForge and love it. Okan has stated many times that Pixie's development is based off of how many people are using it and that is why, I guess, development has dipped in recent years. The main issue, to me, is Pixie needs developers for plugins for 3rd party 3d applications. I'm not talking about scripts, but rather tightly integrated solutions like how Renderman is for Maya. Scripts stiff force the user, in the end, to the use the command line interface to render frames. This is fine for advanced users (or linux users), but most 3d artist just want a simple way to render their images inside the program. Currently there is only one program that I know of that integrates Pixie into it's application the right way - K3D, but it's still in it's early development stages.
To me, this is why Pixie has lagged behind other renderers that I think are inferior. Another problem is that, since Pixar has closed the Renderman format, Pixie's orginal goal of a Renderman compliant renderer is very hard achieve. Do you stop with the 3.2 spec or do you continue development and risk breaking compatibility? I don't know, but I really like where Pixie is at right now and as long as Okan fixes bugs and keeps Pixie up to date with hardware/os changes, I'm happy; I can write my own shaders and functions. One thing I don't want is for Pixie to turn into Aqsis, I don't use that renderer for a reason. Pixie is a powerful renderer, with a simple interface (for those of use who don't mind the command line and RIB files), that is both flexible and expandable. This is how I would like for it to stay.
Sorry about the incoherent post; I hope some of it made sense.
I have been using Pixie steadily for six years now, and as richard_layman I'm quite fine with they way Pixie currently is, except for the occasionnal bugs and sometimes the lack of CSG. I remember back then, I used POV-Ray and I got curious after seeing an incredibly realisticly-looking apple illustrating the power of shaders. I was stunned by the speed and the flexibility of Pixie (I guess due to the RenderMan approach), I adopted it. I remember the time hesitating between Aqsis with its lack of raytracing, and Pixie with its lack of CSG. The lack of CSG is by far the easiest to work around, hence my going with Pixie. I don't know what rechard_layman has against Aqsis, I know of almost nothing about Aqsis except its lack of raytracing, though I'm a bit curious his reasons.
Anyway, I still manage to work around lack of CSG usually quite easily, and that's really only thing I occasionnally miss. Other than that and the occasionnal bugs (I'm currently cooking a test case for artifacts in occlusion() when a glass object is present), I'm blissfully happy with the current version of Pixie.
Now that I'm thinking about it, would it somehow help Pixie if I advertised my using it? I'm far from being a good artist, but I do have a public gallery, only in French for now, though an English version along with an account in gfxartist.com have been procrastinated for months.
Well all us are agree then: Pixie rocks.
But, why has that abandoned filling around it if have so convincing followers? I've search on Google, Youtube, Vimeo for Pixie works and the only thing I found is the Wiki gallery (with a last update on 2008!!): http://www.renderpixie.com/pixiewiki/Examples/User_Gallery
On Pixie homepage says clear: "We need your feedback to keep this project alive. Use Pixie, submit bug reports, pictures you rendered with Pixie or just your good wishes.".
Where can be found your works? What modelling and animation tools are you using? Do you use it for a VFX production, or know someone?
Nephtys, the test case will be very useful to fix the bugs. I can't found our gallery on gfxartist, how is the link?
What do you think is missing to make a Pixie Users community? A Forum maybe (phpbb) ?
As I said, I'm not on gfxartist.com, it's still under heavy procrastination. My thesis work is just taking all my time.
You can find about half of my public images at http://instinctive.eu/dessins/ , the other half being in backups from an older website and waiting to be put online when I get the time to do it. It's in French, but at least you can look at the images and get a feel of my artistic level.
I don't know anyone else using Pixie; my use is only a hobby; and I don't use any graphic tool besides Pixie, and occasionnally the Gimp for some post-processing. My image creation flow involves vim, gcc, and Pixie used as a library (libri). I don't have a good feeling of graphical tools, I just make the scene in my head, and then program it in C using a bunch of Ri* calls and let Pixie perform the actual render from the generated geometry.
I haven't contributed to the wiki gallery you linked because I understood it as a page of examples of a specific feature, and my images don't give much more than what already exists there. However I think I would be more comfortable with spreading links to my website (probably to the future English version) and/or to my future gfxartist account rather than spreading around images, if that's not too much of a problem.
IMHO pixie just has no good way to get scene from aritsts.
People who has maya in most cases has PRMAN. People who uses blender has only ribmosaic. Excuse me WHiTeRaBBiT but it's not looks like a way to go for me. I had almost same exporter known as ribber-0 and ribber-1 it's ok to render cubes and spheres. But nothing to do real projects with hard deadlines.
I hope blender 2.5 will make much easer to write a good, well integrated, easy to use and powerfull exporter to renderman. And even not exporter but integration. Most people don't like to export then render. They want just render.
Exactly; that's the whole problem. The artist wants to see what the scene is looking like as they are working on it, not when they are complete, and they don't want to spend the time exporting it or putting faith in a script that may, or may not, work. When I was a freelancer the only reason I used Mental Ray was because it was integrated into Maya. When I left Maya, after the AutoDe$k takeover, I was happy to leave Mental Ray and make Pixie my default renderer (which I had used for a long time up till then). But finding a 3d application that had Pixie integrated into it like how MR was in Maya, wasn't around. I tried every script and, just like akhilman said, for simple scenes they would work but would break under any heavy load. So I resorted to writing my own scripts which wasn't hard for me since I know C/C++, Python, Ruby, etc. but, then again, most people who already use Pixie knows these languages and a few more. So I wrote my own scripts and they worked, but still sucked because pretty much all scripts suck for any 3d application due to their slowness and how they are not tightly integrated into the app like a plug-in would be. I wasn't that happy with Blender anyway so I left them and started my own C++ 3d application which I'm still working on that uses Pixie as it's default renderer. I was looking into joining the K3d team, but I loath GTK with a passion; sorry - but I'm a big Qt fan.
Anyway, what I'm trying to say is that we could create nice looking web pages, forums, galleries, and the like, but it's not going to make that much of a difference until we get an app that has tight Pixie integration. We may be able to get people to try it with nice gallery images, but we'll loose them as soon as they try to make there own stuff and see how hard it is. Lets face it, there's a reason why most of the people that use Pixie are developers; I would go as far to say that there are more people that use Pixie that know how to code then those that don't. So, in the end, Pixie fills the need of a niche market - us. That doesn't mean that Pixie can't become a renderer used by lots of other artist; it has all the built in functionality to do so, it just needs a developer willing to code a plug-in for it. If a Blender plug-in developer had took it upon himself to integrate Pixie into the application, I don't think we would be having this talk now.
Well RenderMan renderers in general are often said to be "renderers for engineers". Lots of potential out there (and Pixie is no exception), but there are a significant learning curve and required skills.
BTW, we're also building a 3D app, but a Cocoa one, that should provide the kind of integration you're describing. And if it can be used to make test cases for Pixie and make it evolve more easily, that's just fine! Building that kind of app is no small task though, as you need advanced data structures for the scene, interactive backend (GL), + the RenderMan renderer bridge as well. That's probably why there are not that many offering in that field (but big names).
I love Pixie, and I love that there are many people enthusiastic about it. I was trained on PRMan in college, and now work for a small studio that cannot afford to buy a full PRMan pipeline. Pixie is therefore a godsend.
I am working on a commercial production where we are using Liquid for Maya as our RIB exporter and Pixie as our renderer. Pixie offered us a RenderMan-Compliant pipeline at significantly less cost to implement on our in-house render farm. We like that it is open and free, so we can scale our rendering power without software costs. As a very small studio, it helps us greatly to be able to create high quality images in a professional workflow at low software cost.
After production wraps, I plan to report back here with a lot of information from my experience using Pixie in a production environment. And images, of course.
Regarding integration into 3D suites:
In the way I use Pixie integration is far less important. To me, externalizing rendering to make it portable and scalable is its greatest strength. Working with Liquid for Maya, integration is good enough, although somewhat wonky. But I can set RenderMan attributes and assign shaders right in Maya, and then kick out preview renders without jumping to the command line. I am very content with Liquid as a mediator. It's a little rough around the edges, but hey, that's Open Source sometimes…
My interests in moving Pixie forward:
- achieve greater stability in pointcloud/brickmap workflows for production-level scenes. I have had problems with these, although wonky work-arounds can solve those problems. I probably should post my files to the bug tracker…
- maintain parity with PRMan wherever plausible
- some native point-based sub-surface scattering would be really nice
- I am very interested in a native wavelet noise function
- my personal goal for future contribution: using specific production examples from my experience, create training materials on the wiki to help artists understand how to use Pixie in production.
I look forward to hearing more ideas from fellow Pixie enthusiasts.
eibriel, I've finished the test case I mentionned earlier, and I've just posted it in the sourceforge bugtracker. This is the first time I use this bugtracker, I hope I did everything right; in case something is wrong please tell me I'll do my best to fix it.
Regarding the "renderer of engineers" discussion, I think my approach of CG is quite unusual, but I'm just trying to compensate a pathologic inability to use interactive drawing technologies (I don't manage to do anything neither with paper-and-pencil nor with digital tablet or with mouse) with sheer coding skills. As far as the artistic quality is concerned, I let you judge, I just can't make any positive remarks on anything I do. And I'm afraid my lack of interest in interactive interfaces means I won't be of anyhelp at integrating Pixie in these.
I'm glad to see there are still that many Pixie users (yes that's only 6 in this thread, but that's still much more than I feared).
liquid for maya is nice exporter. I had started to learn renderman from it.
And yes. Exporter should provide things like custom shaders, custom attributes, AOV, RibBoxes etc.
But it should also allow just select some shader, select some profile and push render. And renderer should make good enough image. Only after that artist would like to increase quality by special features.
I suppose to blender guys to join together and develop something really nice. Even not only exporter but a service with integrated on-line shader library. But this is only after 2.5's API will be done. Now we should learn how good exporters for maya wors. Liquid maya one of this exporter
I'm following the discussion with interest, could be resumed, in order:
* Pixie need integration with 3D software.
At time (but not Pixie specify):
- Maya: Liquid
- Blender: Ribmosaic
* Pixie need a Gallery, and Showcase ( for instance: ehoch works).
* Pixie works fine, only need regular bugfixes. And eventually some actualization.
I'll keep learning the code (on this time I'm reading Pixar Papers, and Reyes / Raytrace information), and I will release a Pixie optimized Ribmosaic (cause is optimized to 3Delight, and some options don't work).
I'm happy to know about some other people interested on Pixie :)
Just optimize speed and quality of the GI solution and you'll get much more attention. When Pixie offers flexible and fast GI with controllable artifacts you'll gather much more users, even if there is no perfect integration with some 3d software, there will be huge interest in developing exporters to use Pixies GI solution.
Look at all open source raytracers, they gather so much people just because the relatively easy GI use, even those solutions are not fast enough for production.
When you optimize the GI for speed this will get attention from the professional artists - then you'll get beautiful images and Pixie community will grow exponentially.
I'm wondering whether the Renderman Interface is suitable for GI-heavy scenes. I mean, it was developped with REYES in mind, so how difficult would it be to implement any GI on top of that? Let's take for example Metropolis Light Transport, would Pixie need deep internal architectural changes to support it? Would it be easier to make a MLT-renderer from scratch rather than add it on top of Pixie?
These are questions, I'm far from knowing enough Pixie code to answer, but isn't the flexibility of Renderman Shaders a handicap when it comes to more complex models? Or the fact that Renderman interface is surface-based rather than volume-based?
Or would it be better to imagine some REYES-based GI, like a generalization of the multiple-shadow-map trick for ambient occlusion?
The RI was not created with REYES in mind. This is a misconception. Describing a scene is also a problem which is completely decoupled from rendering that scene with global illumination. There is no problem here.
How a RMan compliant renderer creates the image is completely up to this renderer. REYES has absolutely nothing to do with RenderMan. BMRT was a non-REYES renderer which was RMan compliant. AIR is not a REYES renderer and is RMan compliant. Finally, modern REYES implementations have little in common with the original paper.
The hider concept allows a renderer to implement different algorithms for primary visibility. 3Delight e.g. has a raytrace hider which makes the renderer shoot rays through pixels instead of using REYES.
I don't know what REYES-based GI is? REYES doesn't allow for true GI. You need non-local data. For anything but ray-tracing, this commonly requires a pre-pass. For REYES only, this could be illumination maps. But in any case, today's RMan renderers are all hybrid (except Aqsis). So you can choose between 2-4 different algorithms to render GI effects (spherical harmonics/image based, ray-traced, point-based, photon mapped).
Writing physical plausible BRDFs is easy in RMan SL. Most big studios have an arsenal of such shaders. Global illumination just meas that light arrives through indirect paths at the point being shaded. It says nothing about the BRDF (and it physical plausibility) or the emitting light (and the physical plausibility of its implementation). For example, people have used toon rendering with GI and they also have used (and frequently do use) lights with physically incorrect non inverse square falloffs to shine light which then gets bounced around leading to incorrect GI, but GI still. So again, this is mixing up two different concepts.
In short, there is no issue with the RI (including RSL) & GI.
REYES is a not a limiting factor for Pixie since, like 3Delight, AIR & PRMan, it is true hybrid renderer.
I dislike pixies rayes implementation because of it eats a lot more memory then even aqusis in cases when shading rate lower then one. I think pixies rayes even less efficient then raytrace. Hope someone will fix it.
Ok, I've rewritten this post now over three times because I can't find a way of not sounding like a prick, so I'll make it short:
MLT renderer's = Basic
RI renderer's = C++
Not trying to start a flame war here, but you can't say that any RI renderer is less flexible then a MLT renderer. Plus, GI is highly overrated; LightScape was really easy and you could make some really nice renderings, but it was pretty useless outside of the architecture field (just like Maxwell is today).
You guys might want to switch to a DVCS like Git or Mercurial for easier branching and merging, so you're not dependent on any global SVN write access. Perhaps fork the code to github.com and continue it there.
No need to generate additonal work, that btw adds zero value to Pixie, by moving the project elsewhere.
SourceForge does have GIT support.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.