Category: Media Design

Each session ran with somewhere between 5 and 10 people – not a large group, which matters for how much weight to put on what follows. Out of that group, I got 4 responses to the feedback survey. That’s a small sample, and I’m treating the results accordingly, with a healthy grain of salt. But small or not, it’s the first real signal I’ve had on how the course landed, and after two sessions of getting nothing back at all by email, even a handful of honest answers felt like a meaningful upgrade.

The Numbers

The average rating came out to 4.5 out of 5 – three people rated it 5 stars, one rated it 3. That one 3-star rating is worth sitting with rather than averaging away; without more written context from that specific respondent, I can’t say exactly what fell short for them, and that’s a small blind spot in a four-person sample that a larger survey would have filled in.

On pace, two people said it was “just right,” one said “too fast,” and nobody flagged it as too slow or inconsistent, which suggests the difficulty curve across the three sessions was reasonably well judged. That “too fast” answer lines up with something I noticed myself in session two, when the fish-in-a-bottle task pulled in more techniques than any single exercise really should – so that data point tracks with my own read of the sessions rather than coming as a surprise.

Asked which of the three projects they found most useful, the split leaned toward the final session: one vote each for the first and second sessions, and two votes for the third. Nobody selected “all equally,” which I read as a good sign – it means the sessions were distinct enough from each other that people had a real preference rather than defaulting to a neutral answer. The lean toward session three also makes sense given it was the most varied session, covering both retouching and mockup work rather than a single combined exercise.

On confidence using Photoshop independently after the course, the results were more spread out: nobody said they felt “not confident yet,” one person landed on “somewhat confident,” two on “fairly confident,” and one on “very confident.” Given this was three two-hour sessions and not a semester-long course, having the majority land in the upper half of that scale feels like a reasonable outcome, and having nobody land at the bottom of the scale suggests the pacing didn’t leave anyone behind entirely – which was one of my bigger worries going in.

What People Wanted Changed

The open feedback was short but useful. One response asked for the files ahead of the session, noting that scanning a QR code and emailing yourself the material mid-session felt unnecessarily stressful – which lines up almost exactly with the file-transfer frustration I ran into myself from the presenting side, so it’s reassuring in a way to see the same friction point show up independently from the student side. Two people wrote some version of “nothing” – happy with the format as is, which I take as a decent sign the overall structure doesn’t need a rework, just refinement. One simply flagged the time slot itself as the thing they’d change, which is useful to know but not something I can fully control given it’s tied to the FH’s own scheduling rather than anything I decide.

The Real Takeaways

Numbers aside, two practical lessons stood out from running the course. The first is that file transfer needs to be smoother – the FH SharePoint QR code system worked maybe one out of every three times, and having that fail live in front of a room is not a great use of anyone’s patience. Between that and the student feedback asking for files ahead of time, the fix is fairly obvious: send the material out in advance rather than relying on an in-room QR scan that may or may not cooperate that day.

The second lesson was less about Photoshop and more about equipment: always carry a backup adapter. The final session nearly didn’t happen because my adapter stopped working for the beamer with no warning, and the only reason the session went ahead on time was that a friend happened to have one I could borrow. That’s not a mistake I plan on repeating – a spare adapter is going in my bag permanently from now on.

Taken as a whole – the ratings, the specific feedback, and the operational hiccups – I’d call the course a genuine success, with clear, specific things to improve before running it again. Nothing in the feedback pointed to a structural problem with the course itself; the issues were all around the edges – logistics, timing, hardware – rather than the actual teaching or the content. That combination is exactly what you want from a first attempt: proof the format works, plus a concrete list of what to fix next time, rather than having to question the fundamentals of the approach itself.

Getting to teach a Photoshop course at FH JOANNEUM was one of those opportunities that sounds simple until you actually sit down to plan it. The brief was straightforward on paper: cover the basics of Photoshop for other students. The hard part was figuring out what “basics” even means when the software has a thousand entry points depending on who’s using it.

My first instinct was to think about the question from my own workflow outward — what do I actually use Photoshop for, most of the time? The honest answer was 3D-adjacent work: compositing renders, touching up textures, prepping mockups. But that’s not a useful starting point for a room full of students who don’t do 3D work, and building a course around my own niche would have meant teaching people skills they’d never actually reach for. So instead of teaching my own use case, I stripped it back to the tools that show up in almost every Photoshop session regardless of discipline: selections, masks, and the basic adjustment filters like hue/saturation and brightness/contrast. If a student walks away only knowing those three things, they can already do real work. That became the baseline I measured every other decision on.

Structuring the Sessions

The course was split into three sessions, two hours each. Before touching any Photoshop content, I built a short Canva presentation to open every session with — covering terms that get thrown around constantly but rarely get explained: DPI vs. PPI, RGB vs. CMYK, and the common file formats people are expected to already know. I’d rather spend ten minutes on vocabulary at the start than have someone quietly confused for the next two hours.

I also made a deliberate call early on about AI tools. It would have been easy to lean on Photoshop’s generative features and call it a day, but that felt like it would teach a shortcut without teaching the underlying skill. So the focus stayed on the actual mechanics of Photoshop — the idea being that if you understand selections and masking properly, the AI tools become an accelerator rather than a crutch. Running alongside that was a second thread I wanted every session to reinforce: non-destructive workflow. Adjustment layers over direct edits, smart objects over flattening. Habits that save you later even if they feel like extra steps in the moment.

One small but genuinely useful addition was Keyviz, which displays my mouse clicks and keyboard shortcuts on screen. For a follow-along format where people are watching a beamer and trying to replicate what I’m doing, seeing exactly what key I just pressed removes a surprising amount of friction — no more “wait, what did you just press?” interruptions that break the flow of the session.

Session 1: Sky, Selections, and a Plane

For the actual task, I gave students a dull, overcast skyline and asked them to replace the sky with a vibrant sunset and add a plane into the scene. It’s a small exercise, but it forces you through selection, masking, and matching the light and color of two images that were never meant to sit together. Getting the sky swapped out is mostly mechanical once you understand the selection tools, but making the plane sit convincingly in that new sunset, matching its exposure, its warmth, the direction the light seems to be coming from, is where the exercise stops being a tutorial and starts being an actual creative decision. That last part is where most of the real learning happens; anyone can cut out a sky, but making the replacement believable is a different skill entirely.

I provided the image material myself at the start of the session rather than asking people to source their own, mostly to keep the first session focused and avoid losing time to file hunting before anyone had even opened Photoshop. The session itself covered selections, layers, masking, and simple color grading, and it ran comfortably within the two-hour window — which, going into it, I wasn’t fully confident about.

At the end, I asked for two things: feedback by email, and ideas for what people wanted to see in the third session, along with a heads-up that they could bring their own images if they wanted. In hindsight, the email feedback request didn’t get a single response – a pattern that would repeat for the rest of the course – but the structure of asking at the end of every session was worth keeping regardless. It sets an expectation that their input matters, even if the channel needed fixing later.

Overall, the first session felt like a solid foundation. The task was scoped well enough to fit the time, the concepts built on each other logically, and nobody looked lost by the end. That gave me confidence going into session two, where the technical complexity was about to increase noticeably.

I’ve been using Blender for almost eight years now, and for basically the entire time, Cycles (and occasionally Eevee) has been the only render engine I’ve ever really worked in. That’s long enough to get genuinely comfortable with a tool – comfortable enough that switching to something else stops being an obvious idea and starts being a small act of stubbornness to even consider. When you know exactly how a piece of software behaves, exactly which node does what, and exactly how to fake the effect you want when the built-in tools don’t quite get there, the cost of relearning all of that from scratch starts to feel a lot bigger than the potential upside.

The project that pushed me to finally look elsewhere was a university piece I worked on with the Moya Boys: a screen-mapping project where I designed an original tech device meant to visualize the connections between everyone who attended Generate26 – a kind of physical object that made an abstract social network tangible. I modeled and rendered the whole thing in Blender using Cycles, since that’s the workflow I know inside and out, and the result held up well enough as a piece of product design. It was the kind of project that leaned heavily on getting materials and lighting right – glass, plastic, brushed metal, a glowing screen – which meant I spent a lot of time in the shading tab making small adjustments to get surfaces to read correctly.

But working on that project put me deeper into product visualization than I’d been before, and once you start paying attention to that space, Octane comes up constantly. Every comparison video, every side-by-side render breakdown, kept pointing at the same thing: Octane handles caustics and reflective, refractive shading in a way that just reads as more physically convincing than what I was used to getting out of Cycles. The light behaves more naturally – less like a render, more like something that was actually photographed. Watching enough of those comparisons back to back eventually tips you from mild curiosity into actually wanting to try it yourself.

Normally, trying Octane would mean paying for a subscription, which is enough of a barrier that I probably would have kept putting it off indefinitely – there’s no shortage of things worth learning, and a recurring cost tends to push a “maybe someday” idea further down the list. But it turns out Octane has a free version specifically for Blender, which removed the one real excuse I had left. So I decided to actually set it up, work through my old project’s assets in it, and compare the workflow directly against the Cycles version I already knew well. Going into it, my expectations were fairly modest: install the plugin, swap the render engine, see how the same scene looks with a different set of shaders doing the work underneath. What I didn’t expect was how much of the actual learning curve would have nothing to do with rendering quality at all, and everything to do with the setup, the interface, and the countless small conventions that Octane simply does differently from Blender’s native tools. That turned out to be most of the story, and it’s worth telling in full rather than skipping straight to the pretty pictures. What follows is everything that went into getting there – starting with the setup itself, which turned out to be its own small adventure before I’d rendered a single frame.

Once the interface stopped fighting me, the underlying logic of building materials in Octane turned out to be more familiar than I expected. Most nodes have a direct counterpart on the Cycles side – the equivalent of an Image Texture node in Cycles is called an RGB Image in Octane, and the big all-purpose shader that plays the role of the Principled BSDF is simply called the Basic material. Once I had those name mappings in my head, building out reasonably complex shaders wasn’t much slower than doing the same thing natively in Cycles, since the underlying logic of plugging texture inputs into a base shader is basically identical between the two.

Where things diverge more noticeably is environment setup. Blender has a native environment texture node you can just point at an HDRI and go – one node, one image, done. Octane doesn’t offer that shortcut – you need an RGB Image node feeding into a separate environment shader, which is an extra step but not a difficult one once you know it’s expected. It’s a small thing, but it’s exactly the kind of small thing that costs you ten minutes of confused searching the first time you hit it, before it becomes second nature.

Lights Turned Out to Be the Real Culprit

Lighting is where the two engines diverge the most, and where I lost the most time relearning something I thought I already understood. In Cycles, I almost never touch a light’s shader directly – intensity, size, shape, and color all live conveniently in the light’s properties panel, and that’s usually all I need for a full lighting setup. In Octane, most of those same settings simply aren’t in the properties panel at all. Intensity in particular lives in the shading window, meaning every light adjustment meant leaving the panel I expected to use and going back into the node editor instead – a small context switch that adds up when you’re trying to nudge a dozen different lights into place one at a time.

There’s also a more fundamental difference in how the two engines treat lights visually. In Blender, a point light is invisible to the camera no matter how large you make it – to actually see a light source in a render, you need to build a separate emissive material and apply it to real geometry yourself. Octane doesn’t work that way by default: its lights are represented as actual visible shapes in the scene, not just implied sources of illumination reflected off other surfaces. That’s a genuinely useful default for product visualization, where you often want the light source itself to be visible as part of the composition, but it meant every light in my scene needed to be rebuilt from scratch as an Octane-native light rather than simply carried over from the append.

The genuinely confusing part was how intensity and size interact. Making a light physically larger while keeping the same power setting could suddenly make it far brighter, in a way that didn’t track intuitively with what I was used to from Cycles’ units, where increasing a light’s size generally softens shadows without wildly swinging overall brightness. I never fully nailed down the exact relationship between the two values – I mostly adjusted by eye, nudging size and power back and forth until each light roughly matched what I remembered from the original scene. Cameras, by comparison, were a complete non-issue; they carried over from the old file with no adjustment needed at all, which was a small relief after everything the lights had put me through.

One smaller gap worth mentioning: there’s no dedicated “glass” shader shortcut in Octane the way there effectively is in Cycles. To get a convincing glass material, you build it out of a specular shader with the roughness pulled down and transmission dialed up – not a dealbreaker, just a bit of vocabulary I had to relearn.

Once Octane was actually rendering something recognizable, the next set of obstacles weren’t conceptual – they were just Octane doing familiar things in unfamiliar places. None of these were deal-breakers on their own, but together they added up to a surprising amount of lost time.

Denoising Is Hiding Where You Don’t Expect It

In Cycles, denoising lives exactly where you’d look for it – in the render settings. In Octane, it isn’t there at all. Instead, you have to open the properties panel from inside the viewport itself, using the N key, and enable denoising from there. Normally the properties panel mirrors what you’d see on the right-hand settings tab, so having a setting that only exists in the viewport version and nowhere else was disorienting the first few times I went looking for it.

Two Output Systems, and I Only Wanted One

Octane comes with its own dedicated output panel, which on the surface is a nice upgrade – more options, more control. But the default behavior caught me off guard: rendering a single image produced five separate output images at once, which for what I needed was just extra clutter. I’m used to Cycles, where you deliberately set up separate view layers or render passes only when you actually need something like a depth map alongside your main image. Octane just gives you all of it by default.

That doesn’t sound like a big deal until you scale it up. My animation was 513 frames long. At five outputs per frame, that would have finished as roughly 2,500 individual frames – five times the disk space for a result I didn’t need in that form. I ended up switching back to Blender’s standard output system, which is still available alongside Octane’s own – though having two separate output windows sitting side by side in the interface is its own small source of confusion.

The Convert Material Button, With Reservations

One thing that did genuinely help: the Octane add-on ships with a “convert material” button, which attempts to translate an existing Cycles shader setup into an Octane-compatible one automatically. I’d gone in assuming I’d have to rebuild every material from scratch, so this was a pleasant surprise when it worked – somewhere around half to sixty percent of the time, it did.

The rest of the time, results were mixed. Occasionally the conversion wiped the node tree entirely, leaving nothing behind. More often it partially converted but dropped information along the way, which meant I had to manually rebuild specific materials – particularly the device’s buttons, which relied on several layered images stacked on top of each other that the converter didn’t carry across cleanly.

Rearranging My Screen for Octane’s Node Editor

The last adjustment was purely about screen layout. Blender’s default shading workspace splits the screen horizontally – viewport on top, shader editor on the bottom. Octane’s node trees, by contrast, are tall. Very tall, especially once you factor in that most nodes come with collapsible sub-sections that are open by default and that you rarely close, since you might need them later. Working in that default horizontal layout meant constantly scrolling to see the whole graph.

I ended up rearranging my workspace so the viewport sits on the left side of the screen and the shader editor takes up the right side vertically, giving the node tree enough room to breathe. Once I made that change, actually building materials in Octane felt a lot more natural – which is a good segue into how those materials actually compare to what I’m used to in Cycles.

Getting Octane Installed Was Its Own Project

Because Octane isn’t normally free you can’t just search the add-on inside Blender and install it the way you would with any other plugin. The whole thing is gated behind an additional piece of software: a license server that runs alongside Blender, which is how the company behind Octane keeps track of who’s using it without having to open-source the renderer itself. That gating makes sense from their side, but it meant the installation process looked nothing like the one-click add-ons I was used to, where you download a zip, point Blender at it, and you’re done within a minute.

Finding the actual download files took longer than it should have. There’s no single obvious page – you end up on the Octane forums, which point you toward one of the Blender-specific install threads, which you then have to actually read through to figure out what you’re supposed to download and in what order, since the thread assumes you already know roughly what you’re looking for. I got lucky and found a stable build that matched the current Blender version, 5.1.2, but it took some digging through slightly outdated forum posts to be confident I had the right one rather than a version built for an older Blender release.

First Contact: Materials That Wouldn’t Show Up

Once Octane was installed, my first real test was appending my original Moya Boys file – the one built entirely in Cycles – into a fresh Blender file set up to render with Octane. That went badly almost immediately. None of the materials showed up. Which, in hindsight, makes complete sense: Octane can’t interpret Cycles’ native shader nodes, so of course a scene built entirely around Cycles materials was going to come in broken, with nothing but flat gray or missing surfaces where detailed shaders used to be.

To sanity-check things, I added a plain cube with a basic Octane material applied directly, assuming that would at least confirm the renderer itself was working. Even that didn’t render properly – objects were coming through transparent, and I spent a solid half hour going back and forth trying to figure out why nothing I applied was actually showing up in the render, restarting the render itself, toggling settings, checking whether the material had actually been assigned. The fix, when I finally found it, was almost insultingly simple: restart Blender entirely, not just the render. That single move has since fixed more Octane problems for me than any actual troubleshooting step, to the point where it’s become my default first response whenever something looks broken.

That instability seems to be a pattern rather than a one-off. Blender rarely crashed for me at all in the last few years of using it normally, but with Octane running, I’m consistently seeing one to three crashes per session. Interestingly, it’s not the rendering itself that causes it – actually rendering an image has never crashed on me, even on longer, more complex frames. It’s things like resizing or moving windows within the Blender interface that bring the whole thing down unexpectedly. My read on this is that Octane itself is a solid, robust renderer, but the integration between it and Blender’s interface isn’t handling that connection especially gracefully – the crash feels like it’s coming from the plumbing between the two programs rather than the render engine itself failing. For what it’s worth, Octane also never gave me the “CUDA Error Illegal Adress” error that Cycles occasionally throws even when the GPU very clearly isn’t full – so it’s not all downside on the stability front.

If the material and lighting differences were things I could work through by trial and error, the next two problems were harder to solve simply because there was so little help available for them – and both cost me disproportionate amounts of time relative to how small the underlying issues actually were. Cycles has the benefit of years of accumulated community knowledge behind it; Octane’s Blender integration, being a much smaller and more niche corner of an already niche piece of software, doesn’t have that same depth of collective troubleshooting to draw on.

The Documentation Problem

For a renderer as respected as Octane, the documentation specific to its Blender integration is thin. As far as I can tell, there’s essentially one YouTube channel covering Octane-for-Blender specifically, and that’s also where I first learned the render engine was free and how to install it in the first place. The basic setup I could piece together myself from that channel and a handful of forum posts, but anything beyond that – actual troubleshooting, edge cases, workflow questions that weren’t already covered in an existing tutorial – mostly went unanswered wherever I looked. More often than not, I ended up solving problems myself through trial and error rather than finding an existing answer, which is a very different experience from working in Cycles, where nearly any problem you hit has already been asked and answered a dozen times over on some forum or Stack Exchange thread.

The clearest example of this was trying to render a single output image. Octane will happily give you a multilayer EXR file containing all five of its default outputs bundled into one file, which technically solves the “too many files” problem from earlier, but not the problem I actually had – I wanted one plain PNG, not a multilayer file I’d still have to unpack in another program before I could actually use it. I searched through what documentation exists and asked around, but never found a clean, direct answer for this, and eventually just accepted the workaround as good enough for the time being rather than losing more hours chasing a proper fix. It’s a small annoyance in isolation, but it’s representative of the broader experience of working with a tool that clearly works well once configured correctly, but offers very little help getting there.

The Nightmare that was Motion Blur

Motion blur in Cycles or Eevee is close to a non-event: you flip on a toggle, set the shutter speed, and you’re done. In Octane, enabling the equivalent global toggle did nothing on its own – the render came out exactly as sharp as if I’d never touched the setting at all. After some searching, I found that motion blur in Octane has to be enabled individually, per object, for every single item in the scene – there’s no scene-wide switch that actually works the way you’d expect it to from years of the Cycles equivalent.

Even after going through and enabling it object by object, painstakingly clicking through every piece of the device one at a time, the results in my final render were still inconsistent. The device’s case and screen picked up motion blur correctly, softening nicely in line with the animation’s movement, but the buttons and the dial stayed noticeably crisp against the rest of the object, which had visibly blurred. I never fully resolved why those specific parts didn’t pick up the same blur as the rest of the mesh – I checked that the setting was enabled on those objects too, more than once – and it’s the one issue from this whole process I’d still call genuinely unsolved rather than merely inconvenient.

Cycles vs. Octane: What I Actually Learned

After everything – the install process, the crashes, the rebuilt lights, the motion blur that never fully cooperated – the actual point of this whole exercise was always to compare the two engines directly, using the same project as the test case. So how does that comparison actually shake out?

Looking back at the whole process, a few things stand out beyond the individual technical hiccups. The biggest one is that Octane is noticeably less forgiving of imperfect geometry than Cycles. My render came out with a handful of visible shading errors that I’m fairly confident trace back to mesh issues I never had to think about or fix in the original Cycles version – small overlapping faces, slightly non-manifold sections, the kind of thing you accumulate over a long modeling process and never go back to clean up because nothing ever visibly complained about it. Cycles seems to quietly absorb those kinds of geometry problems in a way that Octane puts right on display, which reframed a chunk of what I assumed were rendering issues into modeling issues I’d simply never had to confront before.

That said, I’d call the whole experiment a genuinely fun one, and I plan on continuing to learn Octane rather than treating this as a one-off experiment I ran once and set aside. For now, though, I still think my Cycles version of the render looks better overall – not because Octane is worse, but because I simply have years more experience pushing Blender’s native node tree in specific, sometimes unconventional directions to get an exact look I’m after. There were effects in the original render, like a pixelated screen look on the device’s display, that I wasn’t able to reproduce in Octane in the time I had, mostly because I haven’t yet built up the same instinct for which combination of nodes gets me there.

The two renders don’t look identical, and I don’t think they were ever going to. The Octane version came out noticeably brighter overall, which I don’t necessarily mind – it’s a different read on the same object rather than a strictly worse one – and it clearly plays to Octane’s actual strengths: realistic light behavior, convincing reflections and refractions, the caustics that got me interested in the first place. But getting the most out of that strength seems to demand a higher-quality mesh than what I was feeding it here, given how much more visible those small geometry issues became. Which, if anything, just gives me a clear next step: build something specifically for Octane next time, with clean geometry from the start, rather than testing it against a model that was designed with Cycles’ more forgiving rendering in mind. None of this changes my overall verdict, though: this was worth doing. Even setting aside which render came out looking better, going through the entire process forced me to actually understand what Cycles has been doing for me automatically all these years – the things I never had to think about precisely because Cycles handles them quietly in the background. Octane made all of that visible by simply not doing it the same way, which is its own kind of education, separate from anything about the final image. That’s reason enough to keep going with it.

Dieser erste praktische Test war weniger als fertiges Stilexperiment gedacht, sondern vor allem als Workflow-Einstieg. Trotzdem lassen sich schon jetzt ein paar Beobachtungen festhalten, die direkt an meine bisherigen Blogeinträge anschließen. Der Stilisierungsgrad einer Hybridanimation entsteht nicht an einer einzigen Stelle, sondern additiv aus mehreren, technisch ganz unterschiedlichen Ebenen (z. B. Geometrie, Textur, gezeichnete Linie, gemalter Hintergrund). Zweitens zeigt sich, dass Grease Pencil mir als Werkzeug erlaubt, den Grad der Ikonizität eines Objekts nachträglich und relativ unabhängig von seiner 3D-Form zu steuern, etwa durch die Dichte der gestapelten Strokes bei den Blättern oder durch die Art der gezeichneten Outline. Für die spätere Erstellung meines Masterprojektes ist das ein wichtiger technischer Anhaltspunkt. Durch den Grease Pencil könnte ich zum Beipiel denselben 3D-Grundkörper in unterschiedlichen Stilisierungsgraden (z. B. mit variierender Outline-Stärke, Strichdichte oder Texturunregelmäßigkeit) zu rendern.

Beim Modellieren habe ich mich bewusst an einfache geometrische Grundformen gehalten. Die Stadt bzw. die Häuser bestehen im Kern aus schlichten Quadern, der Baum wurde aus einem einfachen Zylinder aufgebaut, und auch die Blätter sind zunächst nichts weiter als simple Spheres. Diese Reduktion war eine bewusste Entscheidung. Ich wollte, dass der eigentliche visuelle “Look” der Szene nicht durch komplexe 3D-Modellierung, sondern gezielt durch Texturierung und den Einsatz von Grease Pencil entsteht.

Nachdem alle Objekte nach der Vorabskizze modelliert waren, ging es an die Texturierung. Nach dem Unwrappen der UVs konnte ich direkt auf den UV-Layouts malen. In diesem Schritt habe ich jedem Objekt zunächst eine Grundfarbe gegeben und diese bereits mit ersten, groben Shading-Details versehen, um ein räumliches Grundgefühl zu erzeugen, bevor die eigentliche Detailarbeit über Grease Pencil beginnt.

Im nächsten Schritt habe ich den Objekten zunächst eine Outline gegeben und anschließend mithilfe von Grease Pencil verschiedene Detaillinien direkt auf die 3D-Geometrie gezeichnet. Für die Blätter habe ich mehrere Strokes bewusst übereinander “gestapelt”, sodass im Endergebnis der Eindruck dichten, buschigen Laubs entsteht, statt einzelner, klar abgegrenzter Blattformen. Im Anschluss habe ich auch hier noch zusätzliche Linien als Detailebene ergänzt. Die Dächer und die Mauer habe ich ebenfalls mit dem Grease Pencil mit gezeichneten Ziegeln und Steinstrukturen versehen. Für den Eingang/Tunnel an der Mauer habe ich mir ebenfalls den Grease Pencil zu nutzen gemacht und ihn einfach auf die Mauer gezeichnet.

Für den Hintergrund der Szene habe ich einen anderen Weg gewählt. Statt erneut 3D-Geometrie und den Grease Pencil zu nutzen, habe ich das Hintergrundbild direkt in Photoshop gemalt und es anschließend als Textur auf ein einfaches Plane in Blender gelegt.

Fazit

Es hat Spaß gemacht sich mit dem Grease Pencil zu beschäftigen und ich bin auch der Meinung, dass es für meine Forschungsfrage hilfreich war sich damit auseinanderzusetzen und das ich eventuell für mein Masterprojekt darauf zurückgreife. Die Bildkomposition ist mir leider nicht so gelungen, aber für ein erstes Testprojekt bin ich zufrieden.

Finale Bilder

In den bisherigen Einträgen habe ich mich stark auf den Stilisierungsgrad als zentrale Stilmittel für Empathie und Glaubwürdigkeit konzentriert. Deshalb möchte ich in diesem Eintrag einen Schritt zurücktreten und die Frage stellen, wie Immersion in der Forschung überhaupt modelliert wird. Meine These lässt sich vereinfacht als Gleichung formulieren: Story + Animation + Sound + Stilisierung = Immersion. Der Stilisierungsgrad ist demnach nicht allein verantwortlich für Immersion, trägt aber einen Teil dazu bei.

Ein naheliegender Ausgangspunkt ist Janet Murrays klassische Definition aus Hamlet on the Holodeck. Murray beschreibt Immersion als das Gefühl, vollständig von einer anderen Realität umgeben zu sein und sich so stark auf eine Erzählung einzulassen, dass die eigene Umgebung aus dem Bewusstsein verschwindet. Wichtig an Murrays Definition ist, dass sie Immersion explizit an das Eintauchen in eine Geschichte koppelt. Das deckt sich mit dem “Story”-Term meiner Gleichung: Selbst die aufwendigste visuelle Gestaltung entfaltet ihre volle immersive Wirkung erst im Zusammenspiel mit einer Erzählung, die das Publikum emotional bindet.

Differenzierter wird das Konzept bei Ermi und Mäyrä, die in ihrem SCI-Modell drei Teilarten von Immersion unterscheiden: sensorische Immersion (ausgelöst durch audiovisuelle Reize wie Bild- und Tonqualität), herausforderungsbasierte Immersion (das Gefühl, das bei einer passenden Balance zwischen Fähigkeiten und Anforderungen entsteht) und imaginative Immersion (das Eintauchen in eine Geschichte und die Identifikation mit Figuren). Für Animationsfilme lässt sich der herausforderungsbasierte Anteil zwar kaum übertragen, doch die anderen beiden Komponenten passen sehr gut zu meiner Gleichung. Die sensorische Immersion entspricht in etwa der Summe aus Animation, Sound und Stilisierung, während die imaginative Immersion dem Story-Anteil entspricht. Der Grundgedanke von dem Modell ist, dass Immersion grundsätzlich mehrdimensional ist, kein einzelner Faktor allein erklärt das Phänomen vollständig, sondern erst deren Zusammenwirken. Das heißt, dass ich den Stilisierungsgrad nicht als alleinige unabhängige Variable behandeln darf, sondern als eine von mehreren Faktoren, die gemeinsam die Immersion vermitteln und darüber auch die wahrgenommene emotionale Intensität und Glaubwürdigkeit beeinflussen. Für später bedeutet das konkret, dass ich Story, Animationsqualität (Bewegungsführung, Timing) und Sounddesign zwischen meinen Stilisierungsbedingungen möglichst konstant halten muss, um den Effekt der Stilisierung überhaupt isoliert messen zu können, ansonsten laufe ich Gefahr, Effekte fälschlich der Stilisierung zuzuschreiben, die eigentlich aus dem Sounddesign oder der Erzählstruktur stammen.

Quellenangabe:

Murray, J. H. (1997). Hamlet on the Holodeck: The Future of Narrative in Cyberspace. New York: Free Press.

Ermi, L., & Mäyrä, F. (2005). Fundamental components of the gameplay experience: Analysing immersion. In Proceedings of DiGRA 2005: Changing Views – Worlds in Play. Vancouver: Digital Games Research Association.