Anybody here into non-realtime graphics rendering?

[SharkyUK]

EWW MFC!!!!

😊 Yeah, Yeah... I know! Please don't tell anyone :smile: The truth is, I have been working on quite a few MFC-based projects over the last few years hence had become quite intimate and familiar with it. At the time it was easy just to drop my rendering 'stuff' into an MFC skeleton framework that I had available. (That's my story and I'm sticking to it!)

I fully intend to rewrite the UI in C# / WPF and then use interop to talk to the C++ rendering system. That said it's only recently that I started working with C# and WPF... and I think I like them. One particular quote I read somewhere recently (regarding WPF) seems to ring true though (sadly I cannot recall the programmer's name):

"WPF... making the hard trivial... and the trivial hard..."

Barring that, awesome stuff as ever. One day when I get some time to spare I might try my hand at a basic ray tracer, nothing that fancy though.

I remember making my peers marvel when I wrote code to draw a gouraud shaded polygon (in pascal, in DOS back in 1991?).

Yes mate, do have a go if you can find the time. For some reason it is incredibly addictive and, with your knowledge and experience, I don't think it would take you long to get something up and running. Talking of the 'addictiveness', I really need to stop tinkering with what I have so far as it's at a point whereby I need to seriously re-think what I have and where I'm going to take it. The bottom line is that what I have is actually quite a naive ray tracer. To take it to the next level (my aim is a 'commercial' quality renderer) is a massive step. I've already made a start on the basic framework for a PBRT (physically based ray tracer) but it will be months and months before I see the first pixel rendered with that new system. Thankfully there are no deadlines or constraints with it purely being 'for fun' so I'll just keep plodding along with it as and when I can.

A Gouraud shaded polygon? Memories of a happier time mate! It sounds like you were doing similar stuff to myself at around about the same time, too. I expect you also did the Phong thing as well to make your polygonal models look shiny... :smile:

EDIT: Ask any recent computer science graduate about software rasterisation, DDA / Bresenham and you just get blank looks... it's not like it used to be.

Cheers!

 

[sn00p]

Yeah, although working in 256 colour modes had its limitations! Crafting palettes, those were the days.

I write every piece of Desktop software using Qt, I appreciate that it's probably not that easy to meld Qt and Direct X what with DX being all COMified and Microsofty and stuff! But Qt really does kick ass. I have a strong dislike for C#, mainly because I still see it (rightly or wrongly) as a toy language, for years Microsoft told us it was the future yet didn't develop any proper applications in it themselves! I'm guessing that's probably changed now, but Qt gives me all the things I get from C#, but in proper C++ and has the bonus that it's cross platform.

Here's a screenshot from our software for configuring our new generation of radars:

Qt doesn't have a decent docking framework, so I wrote one from the ground up (actually, it's the second time I've done it...the first time was about 12 years ago in pure win32!), basically replicates the docking system in visual studio (you know with the fancy alpha blending and docking target bitmaps). You can dock windows in tabs, reorder tabs, drag windows out of tabs, pin them to the side. All done as a Qt DLL, so I can drop it into any future projects and get docking windows with zero effort.

BTW, this piece of software is already a bit of a monster, but it's been done right. The actual main application provides a plugin service and class discovery and has a whole load of "interfaces" defined, it loads the plugins who then register their objects, create windows, add items to menus etc. The great thing is that plugins can define interfaces, so you can have plug-ins with plug-ins - ad infinitum! For us it's a massive change as it allows us to add/remove specific features just by either adding or removing the dll from the installer, even if you load something which requires a certain interface it'll check if it's available and if it then it wont bother registering its objects.

Basically, it's like COM, but done in a Qt way. I hate COM, it's overly complex and confusing.

What you're seeing there in the screenshot is the culminating of many plugins all working together, the radar runs a virtual machine, so I've built an IDE into the software which allows you to build the application. Theres a simulator plugin which has virtual signs, virtual targets etc so you can test in the software before trying on real hardware.

Our previous software was just one big monolithic application and you're aware they start to get complex as you add features, can be a complete nightmare maintaining them! At least this way, if I think I need a new feature I just create a new component and off I go!

 

[sn00p]

I don't doubt that graduates couldn't tell you low level algorithms, they're all schooled in java these days. f**king java.

I often find myself modifying c compiler settings on a file by file basis or sticking things in particular places in memory (ok that ones an embedded thing).

My boss changed an emmc module from a 2GB to a 4GB module and did a production run and then was confused why none of the modules worked. The problem we faced was that all the initialisation and handling of data was done by a closed source fat filing system, so all I had to work with was the very lowest level actually talking to the chip, so I ended up having to patch in bits all over the place to convince the upper levels that they were using byte addressing while I was actually converting stuff to block addressing. I was also having to patch responses from the module to trick the upper levels. Took me 2 days to workaround, I do wonder how many graduates could have done it. Not many I guess.

I grew up writing bare metal code, so I'm from a different breed of programmers. Today's programmers with their fancy high level languages and toolkits don't know just how easy they have it.

I just tried to find my abrash zen book, but I think it must be at my parents house somewhere!

 

[SharkyUK]

I've not used Qt before mate. I am aware of it but never been in a position where I've had to make us of it (either professionally or for fun). When I've worked on desktop software it's always been solely for a specific platform, more often than not Windows, hence no cross-platform issues and concerns. It was probably circa mid-90's when I started writing any form of Window-based application though; writing tool chain applications in the games industry (Win32 I believe). As you can imagine, my whole working life has pretty much been Windows based simply due to the popularity of the Windows platform for PC gaming. That said, I have also spent a fair bit of time working on consoles from Microsoft, Sony, Sega and Nintendo and I always enjoyed that. The fact that you had a fixed platform and that you could put together some truly horrific code to workaround shortcomings of the system or to get it to do things that it perhaps shouldn't! Some of the hacks we did on the Nintendo64 were ridiculous! You sound like the sort of programmer I admire and respect; a real nuts and bots and down to the wire coder. As you say, there aren't many left. I have to confess insofar that I have probably 'lost' a lot of my low-level skills thanks to the advances in modern day languages and API's (and the sort of work I now undertake).

Thanks for posting up a few details about the radar application; it looks really interesting. And I like the architectural approach you've taken with it. I really, REALLY wish I could tell you more about what I work on but sadly I am unable to do so. It shares a similar framework to what you describe. I am currently involved in taking the old system (which is still very much in use and the culmination of some 9 years of work) and re-writing it in C#... the 'old' system being C++. Don't groan, it's not all bad...

The 'old' system was/is a skeleton framework (Windows XP onwards) written in MFC / C++. Each and every module is then presented to the framework as a plugin and the system allows for full communication between plugins as needed (or restricted if needed). When new functionality is needed, a new plugin can be written. The code base totals hundred and hundreds of thousands of lines of code but - like you say - this sort of approach makes it manageable. Now, the 'new' system also adopts this plugin architecture but is in C# (and WPF for the GUI niceties among other things). What can I say? I used to share the same thoughts about C# mate. I only started using C# as it was necessary for the system rewrite. 8 months on and I have to say that I am extremely impressed. It is now a very much 'serious' language with great support and a decent level of performance. I would recommend maybe taking a look at it sometime if you ever find yourself in a position to do so. I certainly wouldn't shy away; not now given how widespread it is in so many industries. Ok, it doesn't offer the performance of well-written C++ (for example, gaming and high-performance rendering) but it's not bad. It surprised me. And the TPL (Task Parallel Library) is fantastic. I love writing my own multithreading code but have been blown away the TPL; a relative breeze to use and superb performance. Where performance is critical we simply use interop to drill down to C++ / native code. I'm still learning as I go along but I'm impressed with what I've seen of C# so far.

 

[SharkyUK]

A few more renders I generated earlier today. A massive thanks to Paul Tosca for providing the "Nyra" female character model.

In the following images, each scene is rendered with between 5 and 8 lights (directional lights and area lights) to provide direct illumination. I have then attempted to reproduce the effects of global illumination by inspecting the background imagery and using this to tweak the colour values of the ambient light. This is done by projecting the background image onto the inside of a virtual sphere that envelopes the scene. When rays are traced through the scene, and a ray hits a surface, additional rays are spawned from that point along the surface normal of the object hit and we find where it intersects the virtual environment sphere. We then calculate the colour and intensity of the environment point intersected on our virtual sphere and use that to derive an ambient colour contribution for the object that we hit prior in the tracing process. It's not too dissimilar a technique to environment mapping. I have no idea if that makes sense... it does in my head. Anyway, here are the images. You might just be able to see hints of background / environment colour affecting the female character.


Test Render - Nyra (Garden) by SharkyUK, on Flickr


Test Render - Nyra (Park) by SharkyUK, on Flickr


Test Render - Nyra (Forest) by SharkyUK, on Flickr

 

[SharkyUK]

A quick close up of the Nyra character in the garden scene (sadly the non-physically based nature of my ray tracer means that the skin tones look rather waxy and/or plastic.


Test Render - Nyra (Closeup) by SharkyUK, on Flickr

 

[SharkyUK]

A revised version of the "Outlander" model / scene; with improved lighting and shadowing.


Test Render - Outlander (v2) by SharkyUK, on Flickr

 

[SharkyUK]

A couple of renders using models exported from Minecraft. Although they look relatively basic, they consist of over 10 million polygons...!!!!

Just a basic ambient occlusion pass - no lights, no shadows, no texturing.

Rendering of Rungholt by SharkyUK, on Flickr

With a splash of colour; basic lighting and shadowing.

Rendering of Rungholt by SharkyUK, on Flickr

 

[SharkyUK]

I recently grabbed a few 3D car models from the computer game sim/racing scene (Assetto Corsa) and dropped them into my renderer. There have been no further developments on the rendering side hence I just dropped a couple of area lights into the scenes and rendered them as-is. I did add the factory-like environment on a couple of the images just to provide a slightly more interesting scene (so the car bodywork paint had something to reflect). Photobucket quality... sorry... will get some proper renders done of these soon.

Ferrari 288 GTO

International Formula Masters (2009)

A few Clio V6's (there are a few problems with the underlying 3D mesh geometry hence weird rendering artefacts can be seen in places)

RS500 Cosworth

Nissan Primera (BTCC Pre-Season livery)

 

[SharkyUK]

A couple more renders. The first image uses the "Captain Beefheart" model (kindly donated by the talented Gavin Goulden). I tried to use a rather quickly implemented (i.e hacky) image-based lighting technique but it has resulted in quite a flat looking image.

Captain Beefheart

Render - Captain Beefheart by SharkyUK, on Flickr

This next render is the Cleric Troll sample that ships with the professional software 3DS Max. I exported it, imported it into my renderer and generated the following image. There are only 3 lights in the scene (2 soft-shadow casting area lights, 1 directional non-shadow casting fill light) and HDR was used.

Cleric Troll

Render - Cleric Troll by SharkyUK, on Flickr

 

[SharkyUK]

A few more renders (I really need to pick this project up again sometime).


Test Render - BTCC Nissan Primera by Andy Eder, on Flickr


Test Render - Mazda 787b by Andy Eder, on Flickr


Test Render - Mazda 787b by Andy Eder, on Flickr


Test Render - Mazda 787b by Andy Eder, on Flickr


Test Render - African Girl by Andy Eder, on Flickr


Test Render - Rosy by Andy Eder, on Flickr


Test Render - Leather Boot by Andy Eder, on Flickr


Test Render - Toys by Andy Eder, on Flickr


Test Render - Toys by Andy Eder, on Flickr

 

[SharkyUK]

Software Render by Andy Eder, on Flickr


Software Render by Andy Eder, on Flickr

 

[SharkyUK]

It's been a while since I put anything in this thread so I though I'd update with a few new pics for anyone who is interested.

Basically I stopped writing the homebrew raytracing software that I used to create the previous images. I'd taken it about as far as I wanted as adding new features / optimisations would have meant a fairly hefty re-write. I also wanted to try my hand at something slightly different and something more akin to the technology used in modern CGI and special effects for movies. Hence, I decided to write a physically based path tracer. The path tracer uses true global illumination hence better simulates the radiance of bounced light in and around a given scene. It's also extremely intensive when it comes to calculation and processing of the scene! The initial implementation supports a limited set of material / surface types - metal (partial/ideal specular reflection), Lambertian, isotropic and dielectric. I've also implemented a crude(ish) volume material for simulating participating media, i.e. fog, smoke... although these are currently constant density hence have no variation in them.

Below are a selection of renders from the early version of the the software.

Diffuse (Lambertian) surfaces - global illumination means correct effects of bounced lighting are captured in the output; hence the 'bleed' colour of diffuse objects can be seen on nearby objects.


20160726_TestDiffuse by Andy Eder, on Flickr

The metal materials shown below represent metallic spheres showing ideal specular reflection and various levels of glossy specular reflection.


20160726_TestMetalGlossy by Andy Eder, on Flickr

The dielectric materials below represent glass spheres with differing levels of refraction (indices of refraction). Fresnel effects are calculated (to determine levels of reflection and refraction) and total internal reflection is also supported. Beer's Law is yet to be implemented.


20160726_TestDielectric by Andy Eder, on Flickr

I also implemented Perlin noise so that I could procedurally generate 23 and 3D textures on the fly, such as this marble-like texture.


20160726_TestPerlinNoise01 by Andy Eder, on Flickr

In addition, I added basic support for albedo texture maps. Support for normal maps, etc. will come later.


20160727_TextureImageMap01 by Andy Eder, on Flickr

The following two images demonstrate participating media (particulates in the atmosphere). They are a bit 'grainy' due to the limited number of samples I used to render each pixel. Keen eyes may also notice the caustics generated on the floor below the glass spheres. These are created automatically by the path tracing algorithm.


20160727_VolumeConstantMedium01 by Andy Eder, on Flickr


20160728_VolumeConstantMedium02 by Andy Eder, on Flickr

For fun I also decided to implement a method for simulating motion-blur on moving objects. It works well (but only on spheres at the present time). Now I know the method works I will generalise the process and it will work for any 3D primitive in the scene (that is moving with sufficient velocity).


20160730_TestMotionBlur02 by Andy Eder, on Flickr

 

[SharkyUK]

A few more images showing the path tracing software in action...

Diffuse spheres with random moving spheres (constant environment light).


20160726_TestMotionBlur01 by Andy Eder, on Flickr

Diffuse spheres with random moving spheres and some spheres acting as light sources / emitters (constant environment light).


20160728_TestMotionBlur01 by Andy Eder, on Flickr

Scene to show coloured area lights (which currently emit light in both directions, but will be changed to uni-directional) and the currently supported material types.


20160727_RectanglesAndLights01 by Andy Eder, on Flickr

Another sphere-based test scene (generated for a friend who wanted it as a desktop wallpaper!)


20160728_ExScene01_3840px2048spp by Andy Eder, on Flickr

A quick water test (water surface is quite poorly tessellated).


20160730_TestPLY03 by Andy Eder, on Flickr

A quick glass test - showing a hollow glass sphere / bubble on the left and a solid glass sphere on the right (constant environment light).


20160730_HollowGlassSphere by Andy Eder, on Flickr

Preliminary support for 3D model loading and an improved depth-of-field implementation.


20160730_TestPLY04 by Andy Eder, on Flickr


20160731_TestPLY04 by Andy Eder, on Flickr

 

[SharkyUK]

So far, the previous images generated by the path tracer have been rendered using a constant environment light (i.e. the background colour, which is also acting as a low-intensity light source that lights the scene). That's why the objects in the scene take colour contributions from that background colour and objects can sometimes appear flat.

To overcome this I decided to implement image-based lighting (IBL). IBL is used everywhere nowadays and is a preferred method by which CGI artists provide global scene lighting information. It is a technique that has been in pretty much every movie and show that has used CGI effects over the last few years. In a nutshell, IBL involves the capture of an omnidirectional representation of real-world light data (colour, intensities, etc.) which is then stored in an image. The image is then projected onto a dome (or sphere in my case) and I 'wrap' this around my entire scene. As the image contains the light colours and intensities from effectively all directions I can use this information to light my scene. That way, objects seem more grounded as they take on the colours and intensities of lighting from the image as the light rays are bounced around the scene. By using high dynamic range (HDR) images I can also use the same technique to simulate ultra intense lights such as the sun.

Here are renders generated using lighting information purely from the HDR imagery I've used to wrap the scene.


20160731_TestPLY06 by Andy Eder, on Flickr


20160805_IBL_HollowGlassSphere by Andy Eder, on Flickr


20160805_IBL_TestMetal by Andy Eder, on Flickr


20160805_IBL_TestMetalGlossy by Andy Eder, on Flickr

(Ignore the strange looking lines of graininess in the images in places. This was due to a pseudo random number generator bug (sharing static data across multiple threads! Oops!)


20160805_IBL_TestPLY04 by Andy Eder, on Flickr

The same object (skull) rendered with different lighting environments. The only change was the image used to provide the lighting.


20160805_IBLVariations_Skull by Andy Eder, on Flickr

By using a white-ish material on the tank, you can see how the diffuse surface subtly picks up the environment colour.


20160806_IBL_TestPLY08 by Andy Eder, on Flickr

In the following test scene I used lighting from the low-intensity image environment wrap and specified that the cube's stained glass texture should also be a source of light.


20160809_misc01 by Andy Eder, on Flickr


20160819_Random01 by Andy Eder, on Flickr


20160818_TestPLYMisc01 by Andy Eder, on Flickr


20160823_SceneGoblin by Andy Eder, on Flickr

 

[SharkyUK]

Here are some higher-quality (higher number of samples per pixel) rendering tests I generated with the path tracing software.

This Lego scene took a few hours to render at 1920x1080 with 1024 samples per pixel. By the time the render was complete the software had processed in excess of 50,000,000,000 traced rays...


20160816_SceneLegoSUV by Andy Eder, on Flickr

By using a high quality sampling rate the path tracing process can generate some pretty realistic results (assuming the material properties are correctly simulated). Sadly there is some bad 3D geometry on this Lego Speeder but I didn't know until I had waited several hours for the image to complete generating...


20160816_SceneSnowSpeeder by Andy Eder, on Flickr

Yeah, I was bored and had an Olaf model to hand...


20160822_SceneOlaf by Andy Eder, on Flickr

These Lego scenes turned out well with a decent level of realism. They took between 5 and 10 hours to generate.


20160817_SceneLegoSpace by Andy Eder, on Flickr


20160817_SceneLegoSpace2 by Andy Eder, on Flickr


20160821_SceneLegoStarWars by Andy Eder, on Flickr

This last image (basically the same scene as above albeit with a different lighting environment) took 20 hours to render and it still hadn't converged to a level that was sufficient to reduce fireflies. Fireflies are the bright pixels that are evident in parts of the image due to the scene not having had enough samples to converge to a more realistic result.


20160824_SceneLegoStarWars by Andy Eder, on Flickr

 

[Scrooge]

Clever stuff Andy!!

 

[Cookie]

Looks awesome Andy! I understood at least half of those words.

 

[Budgie]

My eyes can't tell what's real and what isn't. Then i realised none of it is real. lol

 

[botfch]

I haven't read the whole thread (yet) but looks good. :up:

I work with Vray and Octane mainly in the architecture sector but we also do bits and bobs for films/art/ 3D scanning etc.

 

[SharkyUK]

Clever stuff Andy!!

Thanks mate - it appeases the nerd in me. Or should that be inner-geek? F**k knows!

Looks awesome Andy! I understood at least half of those words.

Haha, cheers mate. If you understood half the words then you're already ahead of me The fancy words just make it sound a lot more impressive than it is!

My eyes can't tell what's real and what isn't. Then i realised none of it is real. lol

The Matrix. I'm not saying anything else... *glitch*

I haven't read the whole thread (yet) but looks good. :up:

I work with Vray and Octane mainly in the architecture sector but we also do bits and bobs for films/art/ 3D scanning etc.

Thanks mate. I take it you work primarily as a 3D artist building the assets and putting the environments together? Sounds cool if so I'm not so much of a 3D modeller. I can do it but prefer to use assets already produced by folks far more capable than myself. I have been fortunate enough to work with some great artists over the years in the games and movie industry and many have become good friends. Their talent and skills just blow me away. That's why I stick to the software side of things and prefer the challenge of actually writing the software that takes their work and realises it in 3D goodness on the screen. Admittedly my code has a long way to go compared to the likes of Octane and Vray but I am a single developer, doing this as a hobby and only having spent a few weeks on it so far :tonguewink: (Not that I'm even about to attempt writing a commercial-level renderer!)

 

[botfch]

Thanks mate. I take it you work primarily as a 3D artist building the assets and putting the environments together? Sounds cool if so :smile: I'm not so much of a 3D modeller. I can do it but prefer to use assets already produced by folks far more capable than myself. I have been fortunate enough to work with some great artists over the years in the games and movie industry and many have become good friends. Their talent and skills just blow me away. That's why I stick to the software side of things and prefer the challenge of actually writing the software that takes their work and realises it in 3D goodness on the screen. Admittedly my code has a long way to go compared to the likes of Octane and Vray but I am a single developer, doing this as a hobby and only having spent a few weeks on it so far :tonguewink: (Not that I'm even about to attempt writing a commercial-level renderer!)

Yes and no, I spend most of my time overviewing stuff and filling out paperwork recently... :sweat:

Looks decent already for a hobby project, no doubt how every million dollar program starts. :tonguewink::up:

 

[SharkyUK]

Yes and no, I spend most of my time overviewing stuff and filling out paperwork recently... :sweat:

So... you're a manager!

Looks decent already for a hobby project, no doubt how every million dollar program starts. :tonguewink::up:

Thank you - I wish I had more time to work on it as it's actually a lot of fun. Now I've back in work I don't have so much time unfortunately.

 

[SharkyUK]

A few more test renders - nothing too exciting. I've changed the way some of the 'under the hood' stuff works but sadly it's not a difference you'll see visually. I really need to spend some time working on a BRDF / BSDF for car paint as it's not trivial simulating car paintwork!


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr

Yep - very random stuff. And the cars look so poor Something to work on for the new version of the software...

 

[botfch]

Not sure how relevant this is but pre complex Brdfs (GGX) we used to layer up materials, then blend the materials with a fall off map to simulate reflections based on viewing angle.

 

[SharkyUK]

Definitely relevant mate GGX is a shading model that is often used for rendering of metallic materials (due to the fact it produces a good approximation of the hotspot and tail / falloff of highlights across a surface). Likewise, as you say, more complex results can be achieved by layering and combining BRDF's. I have started to implement a layered system but it needs some re-working. The following image (also posted above) shows a naive approach to a layered setup...


20160819_Random01 by Andy Eder, on Flickr

The wooden tabletop is a multi-layered material with a diffuse 'wood' and specular / glossy veneer combination. Likewise, the right sphere is a diffuse submaterial with a dielectric (glass) material combined to give a nice shiny effect.

 

[botfch]

Cool! I wasn't sure how much is universal and how much is Vray specific.

Amusingly there is a book that's landed on my desk, C++ for unreal engine, apparently I'm to do a cpd on it in 2 months so we can get funding to expand into VR.... not going to happen.

 

[SharkyUK]

Pah, piece of cake mate! LOL! How familiar / comfortable are you with C++ and Unreal Engine?

 

[botfch]

Oh, I know bugger all about coding except for Maxscript, my boss seems to think if you can do one you can do the other.😅

 

[SharkyUK]

Oh, I know bugger all about coding except for Maxscript, my boss seems to think if you can do one you can do the other.😅

Ah - yes. I've no doubt you're an intelligent guy but I think you may struggle to pick things up in a couple of months! It was a nice idea though...! :dizzy:

 

[SharkyUK]

The first rendered image generated on my new rig *grin* It's using a quickly hacked together gold metal effect that... kind of works. I little bit of HDR bloom and DoF was also added for additional oomph.


'Gold' Render Test by Andy Eder, on Flickr

 

[Darren S]

Impressive, if slightly long at nearly 7 minutes...

 

[SharkyUK]

I've just started tinkering with my rendering software again and immediately found (and fixed) a bug that's been bothering me for months. I've also rewritten a few routines to speed things up a bit. And then added a slightly more complex diffuse light calculation. Which immediately negated the performance increase. :tongueout:

All the following images were created using image-based lighting (IBL) and a few area lights to provide nice highlights and brighter areas of light. They're also a bit boring as they were mainly generated to test my new diffuse lighting calculations and to make sure I had fully fixed the bug.


Test Render - Old Man by Andy Eder, on Flickr


Test Render - Punk Pilot by Andy Eder, on Flickr


Test Render - She3PO by Andy Eder, on Flickr


Test Render - Zombie by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr

Work-in-progress using assets courtesy of Oats Studios...


Test Render - Oats Studios Rivergod Skeleton by Andy Eder, on Flickr

 

[SharkyUK]

Meh - a few more.


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr


Test Render by Andy Eder, on Flickr

Pure IBL test scene montage...


Test Render by Andy Eder, on Flickr

 

[SharkyUK]

So... I picked this path tracing project up again over the Christmas break and decided to make a few changes. In fact, I've pretty much ripped the whole thing apart. I decided that, before I tried to add more features, I would try and move it over to use the GPU for its massively parallel number-crunching abilities.

Here's the first result - currently the new software only supports sphere primitives as they are easy to deal with and render really quickly. This scene rendered / converged to the result shown within a few seconds.

Each pixel is effectively assigned its own thread and the GPU goes off to run the various algorithms to determine the final colour of that pixel. I used 6144 samples per pixel. So each pixel had 6144 'view' rays shot through it and then the average pixel colour calculated from all those samples. Each of those rays bounced 5 times; i.e. every time that ray hit something the pixel colour (attenuation) was calculated and bounced off in another direction 5 times. If it hit a light source then the light's colour was added to the colour of the pixel. The way the rays bounce off an object is determined by the materials.

Hence, approximately 1920 x 1080 x 6144 x 5 = 63,700,992,000

So - the GPU calculated some 63,700,992,000 ray traces in addition to performing the math to determine bounce angles, reflections, etc.

The software only supports diffuse and perfect specular materials at the moment, too. A bit limited. And I am only using 5 bounces maximum per ray using iteration rather than using recursion and Russian Roulette to determine when to stop tracing a ray.

It's a LOT trickier organising the scene data for submission to the GPU for processing; it's a bit of a learning curve as I've never used the GPU in this way before (I'm normally sending it polygons to rasterise, not tapping into the compute performance). I'm quickly hitting memory limits, program/kernel limits and so-forth so a good deal of thought needs to be given to how I'm going to make it work. I like a challenge. On the plus side, the rather naive brute-force method I'm currently using (which generated the image) is around 37x faster than my multi-threaded CPU implementation that runs across 8 cores / 16 threads... GPU compute potential is immense.

 

[Daz...]

I wish I had even the slightest idea of how you do this.

 

[SharkyUK]

I wish I had even the slightest idea of how you do this.

It's not too difficult mate. A little bit of maths (trig and algebra), a bit of physics. And 30+ years of computer programming!
I'm lucky in that I've been able to do this stuff both professionally and as a hobby; hence I never get tired of it and enjoy keeping up-to-date with 3D graphics technology for the gaming and movie industry (i.e. 3D computer graphics and CGI in general).

 

[SharkyUK]

A few more test images from the experimental GPU-based path tracer I'm trying to put together.

Added support for simple dielectric materials - e.g. glass, water.

Added support for simple triangle-based meshes (simplified triangle prim constructed from a point and two edge definitions for now). The diamond is a triangle mesh loaded from file. The glass objects also cast nice caustics (i.e. the bright hotspots where concentrated light exits the object having travelled through it).

Another example of a simple triangle mesh (the goblin). All the other objects are generated purely from mathematical equations.

The only other change is that I am now able to render the scene in 'real time' on the GPU. I can navigate / move around the scene whilst the scene is displayed in real time in my application window. Each time the viewpoint moves the render is effectively restarted and the quality drops to a level that allows real time movement around the scene. However, if the camera does not move then the scene converges over time, i.e. it becomes more refined, less noisy over time. This was relatively easy to implement due to the way the path tracer works (using something called Monte Carlo path tracing). I'll try and get a video produced soon that shows it working in real time.

 

[sn00p]

Nice.

I’ve managed to get an apprentice which has taken a load of work off me, took him a while to get up to speed with the Qt desktop software I wrote (he was amazed one person wrote it). I currently have a 24Ghz spectrum analyser set up on my desk in the office as I’ve been bringing up the necessary code to drive our own design of radar antenna, culmination of a years work!

 

[STEVE.M]

Can any of you check your tyre pressures?