Jump to content

mondi

Members
  • Content count

    43
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mondi

  • Rank
    Peon
  • Birthday 04/18/1980

Contact Methods

  • Website URL
    http://www.dyskinetic.com

Personal Information

  • Name
    mondi
  • Location
    Stockholm
  1. OpenGL renderer

    Wow, it's been a while. I'm finishing off 2 projects, and working full time at the moment, but if everything works out as I think it will - something.very cool.soon. Here's an old one that's been making the rounds recently - only partially rendered with the old code, but enough to include it in the thread methinks And here's one with some newer code.
  2. OpenGL renderer

    It's a little sad that I only ever update this thread with reasons why nothing's happening I'm in the middle of production again, writing software for a performance at the Bordeaux Art & Architecture Biennale. Happily, a lot of the work I'm doing involves working on the underlying framework, but I just don't have time to revamp the Houdini side of things at the moment. I should be done at the end of the month, so hopefully I'll have something new to show then As an aside - the piece I showed stills from earlier in the thread is playing this week at SIGGRAPH in the 2nd Visual Music reel (återbesök) - Hope someone gets to see it.
  3. OpenGL renderer

    odblog: v1. After some success with testing / planning, started porting the the "old" renderer to the new system - So far I have all the vbo, fbo, shader, and context (osx) functionality in place. It's a little convoluted at the moment to allow for both scriptability and a future upgrade to full OpenGL 3.0 specs, but nothing unmanageable. Next up: 1 - Getting the new image system in place( textures and renderbuffers etc ) 2 - Moving the materials / render techniques code to separate modules 3 - Updating and rewriting the basic shaders and base scripting to reflect all the updates. 4 - Getting the linux stuff (GL context, basic windowing / input etc) written and tested 5 - Updating the Houdini renderer for all the new updates. I'd say the week is well and truly spoken for
  4. OpenGL renderer

    You're quite right, I really should be converting to tri-strips for static models - and the renderer supports pretty much anything you can throw at it geometrywise. It's just that most of the stuff I've been doing is animated, and quite heavy in terms of cook-time. I've been avoiding any unnecessary conversions at the modeling level, so I tend to forget that Good news is - I finally got some time to work on this today. The core library is now completely ported to linux and working well. The hardest part is now down, which was writing the Makefile generator and the component factory, so it should be a pretty straightforward matter to port the older stuff to the new improved system. With any luck I'll be able to get a linux beta together this coming week - fingers crossed
  5. OpenGL renderer

    Haha, me and my big mouth Disclaimers: 1 - Like I said, it's not that quick, but there's absolutely no optimization going on (To the point where I'm uploading each unique vertex, rather than supplying an index buffer and point list). 2 - As you can see, changing parameters forces a cache rebuild, which is probably the slowest part of the whole process. 3 - Im literally plugging the vertex data into a simple material / uv set. There are obvious lighting errors because I'm not supplying any semblance of correct normal data - This is not Buddha at his most aesthetically pleasing So with all that in mind: http://dyskinetic.com/odforce/gl_mv/ Enjoy.
  6. OpenGL renderer

    Ooh - full disclosure: While I did use some code to generate the models for the last image, the primary rendering was Mantra. Sorry for the confusion - although it did get me looking into the possibility of realtime PBR - more on that later I do all the translation for the viewport renderer in C to get stuff done as quick as possible. It's quite possible to do it in script (in fact the first versions of all this were ROP only - so they used SOHO for all the output) but for heavy models this takes far too long to maintain any interactivity. The output module is similar to SOHO. There's a separation between the renderer technique, and the actual output driver, so whether you use the built in techniques (currently just simple multi-pass and deferred: both geared at realtime work) or the script technique, you can still write to a variety of output drivers - So just like SOHO, you could write a script that translates the data to any external renderer.
  7. OpenGL renderer

    After some experiments, I've decided to keep the new scripting language to operator definitions, and anything that needs super tight integration with the innards, and am implementing a python backend for the renderer, as well as general scripting. It doesn't really change much, as the "plugin" system was pretty much built to be accessed from scripts anyway, so its simply a matter of providing the python abstraction layer. With a little luck, I'll be restarting serious dev work over the weekend / next week. Until then: Fun with PBR
  8. OpenGL renderer

    Wow, it's been awhile I've been in the middle of a couple of pretty large art projects, as well as jetting around a little (not as glamorous as it sounds) for work, so development has definitely slowed down a little. News since the last post: 1 - Completely rewrote the base architecture to use a really, really modular plugin system, so any part of the core / any specialized module can be overridden really easily now. This will make it super easy to add stuff like D3D support etc, as well as really easy to add test modules etc - as nothing need interfere with the main codebase 2 - Working on a script subsystem, that uses plain text to build both material techniques, as well as the full blown renderer. So, very soon it will be possible to add effects / custom renderers / custom shading etc with simple script files, with no slowdown. This is easily my favorite new bit, as eventually it'll allow for craziness like switching renderer mid-stream, compositing the results and using that as the input for an effect down the line .. etc etc. Just looking to replicate the current render pipeline for now though , which is coming along well. 3 - Linux port : I'm using Ubuntu / Debian as my test beds .. Like I asked earlier, if there's another more popular distro, I'd like to hear it so I can test .. 4 - Windows port - Still putting this off as I don't have a Windows license and I don't want to develop for beta / RC operating systems. I've got some 'theoretical' code written though. There's a fair amount of stuff there, but it looks like I might have a good chunk of time coming up to do this, so I'll be trying to get something releasable done then. Sorry not to post dates, but things are a little crazy right now.. M
  9. OpenGL renderer

    Another teaser - 1 min or so. http://dyskinetic.com/stest_002/ This whole compression game is an art in itself. I'm still playing with various output settings, I think I can get the whole thing into about 500MB with decent quality, which my host should be able to handle. I'll definitely hit you up if it looks like I'm running out of bandwidth though As for the renderer - still messing around with the more abstract side of things codewise. I really want to get a functional "production ready" version together so I can put this out for testing. A big test will be porting it all to Linux / Windows, although thankfully the lions share of OSX specific code is for window / application management, which is unnecessary for the Houdini DSO. Is there a preferred Linux distribution for running Houdini? I'm most familiar with Debian / Ubuntu but if people prefer SUSE / Red Hat, I should probably look to install those instead..
  10. OpenGL renderer

    Compression and downscaling really flattens everything and pretty much destroys the detail, so heres a short sample for now. I'll have to figure out some way of getting the whole thing online with some kind of reasonable file size later. 1280x720, h.264 http://dyskinetic.com/stest_001/
  11. OpenGL renderer

    Some more stills, I'll render out the animation tonight and post it in the morning. I know this is getting a little off-topic - As penance, I've started writing the 2 main filters used in post for these images, as COPs.
  12. OpenGL renderer

    I've been spending the last few days playing around with some ideas for a short piece. These images are the sort of the aesthetic I'm going for. Working on this has made me focus a lot on the integration, stability and flexibility of the renderer in a more "production" environment, which is always a good thing. There's some post work of course - this isn't representative of typical renderer output, but all the layers going into the post pass are straight out of Houdini. Warning - the film will be 1080p, and unfortunately reducing the image size makes lots of detail disappear - so I haven't resized them at all: One of the big differences coming up will involve me making some new textures to work with, and thus changing the color scheme of everything a little - Although I'm really happy with the palette that the stuff I've been working with has been yielding, so they may just stay on a little longer ..
  13. OpenGL renderer

    Non-poly surfaces are in. This is a working pass, so most pretty stuff is turned off. Base primitives (sphere etc) aren't supported, but all the Hull types seem to work.
  14. OpenGL renderer

    Also - a quick question: I'm looking to add support for non-poly surfaces soon - Am I right in assuming that I can use GEO_Primitive::evaluatePoint() etc in my tessellation routines? - Or is there a better way to retrieve a surface approximation?
  15. OpenGL renderer

    Not currently, but I have plans for an occlusion density attribute, that could trivially be linked to alpha / volume density / material override etc, I'll throw that in when I clean up the current shaders. Hmm - gets me thinking about a some sort of screen (well - light) space light dispersion / transmittance based on alpha and a refraction index .. between that and factoring color into the SSAO pass, you could get some really subtle and beautiful color bleed... hmmmmmm
×