Jump to content

Blogs

FBX Converter Updated

A small update has been published to the default branch of Leadwerks Game Engine on Steam. This updates the FBX converter so that the scene units (meters, feet, etc.) are read from the file and used to convert the model at the proper size. Previously, the raw numbers for position, scale, and vertex positions were read in as meters. The new importer also supports both smooth groups and per-vertex normals, so models can be imported more reliably without having to recalculate normals.

An error in the probe shader that only occurred when the shader was compiled for VR mode has also been fixed.

Josh

Josh

The reincarnation of Vectronic: Vec-Tec

For who those who don't know (or remember) Vectronic was my first person puzzler project I was developing from 2013-2016 starting with the Source Engine and then onto Leadwerks. The goal of the project was to create a puzzle game and allow people the assets to make their own puzzles. Although it never saw it's end, you can still play the demo here. So what happened? Vectronic was how I pretty much learned a lot about programing, art and game design in general. I kept going back working on it for a month or so and then stop because I would hit a road block with assets, code, performance, or time. I made a lot of cool things too that just never saw the light. Over the years however, I also noticed I don't have patience to work on one game alone for months at a time. I do however like to play around with stuff so I began to think: "What if I had a project for me to tinker with and post it publicly every so often?" I'm more busy than I was in the past so time is more limited. However, I've probably written Vectronic game code over 50 times and I now know the right way of doing such. So what's the plan? After some experimentation, I've decided to go ahead and start a new project taking everything I did and learned with Vectronic and making a base template for people can use for their own purposes. My packaged game will be free to download and play (Because it's just me playing around) while the assets and will be posted on the Leadwerks Marketplace for a charge.The package will contain all assets to build your own test chambers, and you'll also get the original source files too! My release game will act as an outlet to my tinkerings and provide as an advertisement to the asset pack. With the code, the idea is that everything will be modular and users can easily create their own power balls to do various of things. The power balls can now be applied to any entity under certain conditions so there is no need for a VecBox.lua script anymore. There will be plenty of examples for many to see how things were done. I learn best by references and examples, and having code, art, and maps accessible should help new users into learning game design, or aiding developers in assets to start their ideas. I've decided to change the name to Vec-Tec as the asset pack will be in the Vec-Tec Research Center. Also with the new approach, I think it's time to drop the name Ive been using for four years. You can give Vec-Tec a try right now here!  It's very minimal, there is no art, but the foundation is there. VR is now gonna be a thing with this, If you have a VR HMD, you can play any map in Roomscale VR! I hope this is a start of a remarkable development. I hope you are interested and see value in this  project. You can find the project page here for the latest updates and releases.

reepblue

reepblue

Turbo Game Engine Beta Updated

An update is available for the new Turbo Game Engine beta. Fixed compiling errors with latest Visual Studio version Fixed compatibility problems with AMD hardware Process is now DPI-aware Added high-resolution depth buffer (additional parameter on CreateContext()). Subscribers can download the new version here.

Josh

Josh

Luawerks Updated

Luawerks has been updated to 1.2.6, making some small adjustments and fixes to the system. If you have previously purchased Luawerks, this update is available for free on the Leadwerks Marketplace. Following changes include: Fixed flag typo correcting LUAWORKS to LUAWERKS Moved error.mat/tex to the Materials/Common folder Added a useuisystem boolean to disable the menu, Adjusted VR mode not to call any UI elements. At this time, this update is only exclusive to the Leadwerks Marketplace. About Luawerks Luawerks is a Lua framework for video games developed on the Leadwerks Game Engine. It supplies developers with additional functions, handles the game loop and allows them to debug their code with a developers console. With all that out of the way, you can focus on making your game fun! You can purchase Luawerks from the Leadwerks Marketplace for $9.99. For documentation and bug reporting, please visit the GitHub page.  

reepblue

reepblue

Pre-Alpha v1.1

After three weeks of work, Pre-Alpha v1.1 is ready.   Terrain The terrain has seen some behind the scenes improvements with speed as well as visual improvements to geometry and texturing.  When I manage to get Texture Arrays working I will be able to finish of the new texturing shader that will include Tessellation and over 16 different texture maps as well as various masks that will paint according to erosion and forest locations. An image of one of the mountains randomly placed in the First World, textured with two 4k textures.  The way the generator works is there is a predefined list of terrain features, like mountains, rivers and valleys.  Based on a low resolution base map which is unique for each fragment, these features are placed at different scales, positions and rotations.  They will also merge with one another to provide enough variation that it will be hard to see any similarities. At the moment though there are not enough maps to make this unnoticeable.           Saving and Loading I have now implemented the ability to save and load a game.  Currently the only states that are saved are the players position, stats and inventory. Each slot shows the date and time that it was saved on as well as the save name and version number.  Slots can be deleted and overwritten.  The version number will change over the course of the updates, but the ability to load older versions will always be available.  And to save a new game, click the empty slot then click save. Now that this mechanic is done I can work on more game play.             What's Next The next step is to improve the blacksmith and general store.  These two places will be the first to provide work opportunities for the player.  These opportunities will improve skill and eventually allow you to buy and use crafting equipment outside of the towns. I will also be implementing some other mercenary characters and animals to hunt.  The mercenaries will just offer some fun conflict to begin with and the animals will offer another source of income.  I hope to have a deer and wolf done by the next update in a few weeks.   The full change log is packaged with the game, here.

Leadwerks Software to Provide VR Services to NASA

TLDR: I made a long-term bet on VR and it's paying off. I haven't been able to talk much about the details until now. Here's what happened: Leadwerks 3.0 was released during GDC 2013. I gave a talk on graphics optimization and also had a booth at the expo. Something else significant happened that week.  After the expo closed I walked over to the Oculus booth and they let me try out the first Rift prototype. This was a pivotal time both for us and for the entire game industry. Mobile was on the downswing but there were new technologies emerging that I wanted to take advantage of. Our Kickstarter campaign for Linux support was very successful, reaching over 200% of its goal. This coincided with a successful Greenlight campaign to bring Leadwerks Game Engine to Steam in the newly-launched software section. The following month Valve announced the development of SteamOS, a Linux-based operating system for the Steam Machine game consoles. Because of our work in Linux and our placement in Steam, I was fortunate enough to be in close contact with much of the staff at Valve Software. The Early Days of VR It was during one of my visits to Valve HQ that I was able to try out a prototype of the technology that would go on to become the HTC Vive. In September of 2014 I bought an Oculus Rift DK2 and first started working with VR in Leadwerks. So VR has been something I have worked on in the background for a long time, but I was looking for the right opportunity to really put it to work. In 2016 I felt it was time for a technology refresh, so I wrote a blog about the general direction I wanted to take Leadwerks in. A lot of it centered around VR and performance. I didn't really know exactly how things would work out, but I knew I wanted to do a lot of work with VR. A month later I received a message on this forum that went something like this (as I recall): I thought "Okay, some stupid teenager, where is my ban button?", but when I started getting emails with nasa.gov return addresses I took notice. Now, Leadwerks Software has a long history of use in the defense and simulation industries, with orders for software from Northrop Grumman, Lockheed Martin, the British Royal Navy, and probably some others I don't know about. So NASA making an inquiry about software isn't too strange. What was strange was that they were very interested in meeting in person. Mr. Josh Goes to Washington I took my first trip to Goddard Space Center in January 2017 where I got a tour of the facility. I saw robots, giant satellites, rockets, and some crazy laser rooms that looked like a Half-Life level. It was my eleven year old self's dream come true. I was also shown some of the virtual reality work they are using Leadwerks Game Engine for. Basically, they were taking high-poly engineering models from CAD software and putting them into a real-time visualization in VR. There are some good reasons for this. VR gives you a stereoscopic view of objects that is far superior to a flat 2D screen. This makes a huge difference when you are viewing complex mechanical objects and planning robotic movements. You just can't see things on a flat screen the same way you can see them in VR. It's like the difference between looking at a photograph of an object versus holding it in your hands.
What is even going on here??? CAD models are procedural, meaning they have a precise mathematical formula that describes their shape. In order to render them in real-time, they have to be converted to polygonal models, but these objects can be tens of millions of polygons, with details down to threading on individual screws, and they were trying to view them in VR at 90 frames per second! Now with virtual reality, if there is a discrepancy between what your visual system and your vestibular system perceives, you will get sick to your stomach. That's why it's critical to maintain a steady 90 Hz frame rate. The engineers at NASA told me they first tried to use Unity3D but it was too slow, which is why they came to me. Leadwerks was giving them better performance, but it still was not fast enough for what they wanted to do next. I thought "these guys are crazy, it cannot be done". Then I remembered something else people said could never be done. So I started to think "if it were possible, how would I do it?" They had also expressed interest in an inverse kinematics simulation, so I put together this robotic arm control demo in a few days, just to show what could be easily be done with our physics system.   Turbo Game Engine is Born With the extreme performance demands of VR and my experience writing optimized rendering systems, I saw an opportunity to focus our development on something people can't live without: speed. I started building a new renderer designed specifically around the way modern PC hardware works. At first I expected to see performance increases of 2-3x. Instead what we are seeing are 10-40x performance increases under heavy loads. Once I saw this I was very encouraged, so I decided to name the new engine "Turbo Game Engine" (the point is absolutely unmissable) and bought the domain name turboengine.com. During this time I stayed in contact with people at NASA and kept them up to date on the capabilities of the new technology. At this point there was still nothing concrete to show for my efforts. NASA purchased some licenses for the Enterprise edition of Leadwerks Game Engine, but the demos I made were free of charge and I was paying my own travel expenses. The cost of plane tickets and hotels adds up quickly, and there was no guarantee any of this would work out. I did not want to talk about what I was doing on this site because it would be embarrassing if I made a lot of big plans and nothing came of it. But I saw a need for the technology I created and I figured something would work out, so I kept working away at it. Call to Duty Today I am pleased to announce I have signed a contract to put our virtual reality expertise to work for NASA. As we speak, I am preparing to travel to Washington D.C. to begin the project. In the future I plan to provide services for aerospace, defense, manufacturing, and serious games, using our new technology to deliver VR simulations with performance and realism beyond anything that has been possible until now. My software company and relationship with my customers (you) is unaffected. Development of the new engine will continue, with a strong emphasis on hyper-realism and performance. I think this is a direction everyone here will be happy with. I am going to continue to invest in the development of groundbreaking new features that will help in the aerospace and defense industries (now you understand why I have been talking about 64-bit worlds) and I think a great many people will be happy to come along for the ride in this direction. Leadwerks is still a game company, but our core focus is on enabling and creating hyper-realistic VR simulations. Thank you for your support and all the suggestions and ideas you have provided over the years that have helped me create great software for you. Things are about to get very interesting. I can't wait to see what you all create with the new technology we are building.

Josh

Josh

Vector Image Support

Building on the Asset Loader class I talked about in my previous blog post, I have added a loader to import textures from SVG files. In 2D graphics there are two types of image files. Rasterized images are made up of a grid of pixels. Vector images, on the other hand, are made up of shapes like Bezier curves. One example of vector graphics you are probably familiar with are the fonts used on your computer. SVG files are a vector image format that can be created in Adobe Illustrator and other programs: Because SVG images are resolution-independent, when you zoom in on these images they only become more detailed: This makes SVG images perfect for GUI elements. The Leadwerks GUI can be rendered at any resolution, to support 4K, 8K, or other displays. This is also great for in-game VR GUIs because you can scale the image to any resolution. SVG images can be loaded as textures to be drawn on the screen, and in the future will be able to be loaded as GUI images. You can specify a DPI to rasterize the image to, with a default setting of 96 dots per inch.

Josh

Josh

Asset Loader Class

There's a discussion on the forum that sort of veered into talking about Khronos' GLTF file format specification: Some of this gave me some ideas for changes in the art pipeline in Turbo Game Engine. I was not feeling very concentrated today so I decided to do some easy work and implement a loader class: class Loader : public SharedObject { public: std::vector<wstring> extensions; virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; Then I created a TEX texture loader class: class TEXTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; When the engine is initialized it creates a TEXTexLoader object and saves it in a list of texture loaders: GameEngine::Initialize() { textureloaders.push_back(make_shared<TEXTextureLoader>()); } And the class constructor itself creates an array of file extensions the loader supports: TEXTextureLoader::TEXTextureLoader() { extensions = { "tex" }; } When a texture is loaded, the engine looks for a texture loader that matches the extension or the loaded file path. At this point, all we have done is restructured the engine to do the same thing it did before, with more code. But now we can add new loaders for other file formats. And that is exactly what I did. You can now load textures directly from PNG files: class PNGTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; I've done the same thing for model file loading as well, although I have not yet added support for any other file types. If we can add a C++ loader, we should be able to add one with Lua too. I haven't worked out the details yet, but it could work something like this: function LoadModelObj( stream, model ) while stream:EOF() == false do -------------- end end AddModelLoader(LoadModelObj) So with that, you could download a Lua script that would add support for loading a new file format. I think in the new engine we will support all common image formats, including Photoshop PSD, as well as DDS, KTX, and our existing TEX files. Textures loaded from image formats will be less optimal because mipmaps will be generated on loading. Settings like clamping and filter modes will be stored in the associated .meta files, which means these files will start getting published along with your game asset files. This is a change from the Leadwerks 4 way of doing things.

Josh

Josh

Pre-Alpha v1.0

The Seventh World is a Medieval Fantasy Survival game, inspired by the likes of Skyrim and ARK Survival Evolved.   It's been under development for the last two years but only in the last eight months has a real commitment been made to it.  Spending every night after work and every other day working on it I've achieved a base from which to build on. The cuboid landmasses are called fragments.  They are arranged as a sphere to make up a planet.  Game-play will eventually include moving from one fragment to another. Each fragment face has a gravity direction toward the center of the land mass.  Each face is known as a World.  The top most face is the First World.  The left, The Second World.  The right, The Fourth World.  The North face is The Fifth World and the South face is The Sixth.  The last face, opposite to the top is The Third World. Each World is separated by an area of weak gravity known as the gravity void, making it difficult to travel between them without the right equipment.  Each world will also have unique features and biome characteristics. In total, there will be approximately 12.5 million square kilometers of explorable terrain.             There is minimal game-play at the moment.  You spawn in one of the procedurally generated towns and the most you can do is; Harvest trees. Drink from the well. Sell/buy items from the shop. Eat equitable editable items. Run around.       What I'll be working on next is fixing the obvious graphics issues.  This will include; Terrain patch seams. Billboard trees and their many issues. Bugs when nearing the gravity void. Distant fragment seams.             The Plan My overall plan is to get this to an alpha stage so it can be released on Steam.  For this stage I want to have the following implemented; VR Multiplayer Building mechanics. Basic Missions. Improved Graphics.   Bug Warning Physics shapes are not releasing and are causing memory usage to increase.   Various other small memory leaks. Crashes in the gravity void sometimes. Feedback and suggestions are welcome.  I hope to have a progress update every one to weeks. Download Here

Test Driving on Mars :D

And the screen, really a pain in the ***..... Well, the test drive on Mars, results with just applying the engine to the rear tires, I still feel it jumps a lot, hopefully in the next leadwerks update to get better control of the joints. Let's hope that update is soon. Another thing is that I think it is impossible to reach high speeds, because it starts to bounce a lot. And happy with the OBS video recording program, he doesn't get slow when he makes a video. Translated with www.DeepL.com/Translator  

Yue

Yue

Glass material

Well, it wasn't the desired result, but it's not that it's too bad, the vehicle's glass looks like this, even though it would have been better transparent, but like many things in life, this is out of my knowledge ("shaders") and it's up to us to adapt to what we have.



Yue

Yue

Steering system realized

Among other things, we already have vehicle glass, which is simple but adaptable to the needs. On the steering rims, they can be moved from left to right with their respective rim headstock. The steering is not automatic at the moment, i.e. it does not return to the central axis without pressing the keys, this has to be done manually, and the speed of the steering rotation will have to be in accordance with the speed of the car in motion. Translated with www.DeepL.com/Translator



Yue

Yue

Motivation has returned

The world moves on the basis of motivation, so again we are here with my learning projects to the limit of being able to think that if I am able to make a game, and is that in Leadwerks, everything is much more wonderful thinking about productivity, of course, there can be better things than this engine, but is what I feel most comfortable with.  Well, the project initially involves rolling a car on the surface of Mars, this is thanks to the work that the engine offers in hinge and sliding joints. I have the job done in the best and most efficient way when the shock absorbers and the engine of each tire, the next step is to set the engine of the car, and set the direction of the front tires so that the scout vehicle can turn and move in different directions on the ground.  So I'll see you in more advance.  Translated with www.DeepL.com/Translator

Yue

Yue

More Work on Shadows

I found and fixed the cause of the cubemap seams in variance shadow maps so we now have nice soft seamless shadows. I also changed the engine so that point lights use six 2D textures instead of a separate cubemap texture array. This means that all light types are sharing one big 2D array texture, and it frees up one texture slot. I am not sure if I want to have a hard limit on number of shadow-casting lights in the scene, or if I want to implement a system that moves lights in and out of a fixed number of shadowmap slots.

Josh

Josh

Three Massive improvements the new engine will make in your life

As I work with the new engine more and more I keep finding new ways it makes life happy and productive. Smart Pointers I have talked about how great these are at length, but I keep finding new reasons I love them. The behind-the-scenes design has been a lot of fun, and it's so cool to be able to write lines of code like this without any fear of memory leaks: LoadSound("Sound/Music/fully_loaded_60.wav")->Play(); What do you think that code does? It plays a sound, keeps it in memory, and then unloads it when the sound finishes playing (assuming it is not loaded anywhere else). Smart Pointers make the new API almost magical to work with, and they don't have the performance overhead that garbage collection would, and they work great with Lua script. User Interface Leadwerks GUI will be used in our new editor, which allows me to innovate in many new ways. But we're also using Visual Studio Code for the script editor, which gives you a sleek modern scripting environment. Better Scene Management Cached shadow maps.are a feature in Leadwerks 4 that separate geometry into static and dynamic shadow-casting types. Static shadows are rendered into a cache texture. When the shadow updates only the dynamic objects are redrawn on top of the saved static cache. This requires that you set the light shadow mode to Dynamic|Static|Buffered. In the new engine this will be automatic. By default lights will use a shadow cache, and if the light moves after the first shadow render, the cache will be disabled. Any geometry can be marked as static in the new editor. Static objects are more optimal for lighting, navigation, and global illumination, and will not respond to movement commands. (This can also be used to mark which brushes should get merged when the scene is loaded). If you don't explicitly select whether an object in the scene should be static or not, the engine will guess. For example, any object with non-zero mass or a script attached to it should not be automatically marked as static. If you didn't understand any of that, don't worry! Just don't do anything, and your scene will already be running efficiently, because the engine makes intelligent choices based on your game's behavior. It's all turning out really nice.

Josh

Josh

Test: Customizable NPC controller

Working out of this subject:   I tested a script for a simple "GoToPoint()" function for a customizable character controller for NPC. This may not be so good as the implemented LE character controller with classic navigation system but it could be promising to use it in open world (so not in much corridored dungeon game!) where the the NPC should crawl or swim or whatever do things as for example underscaled world (thats what I am actually interested in 😁) The NPCs are using an "intelligent" World:Pick() system to find their way. The positive things in this are: - No need nav mesh to be build / free moving system - dynamic way searching so removing a block may let the NPCs go through - swim, crawl, crouch with triggers should be no problem - NPC are not only following a prepared way but they can be thrown as Patrol, choosing randomize positions to go, inside an area. - Scale as you want - The system let the NPC make a little analyse out of the Pick Infos so the way should be a human-logical way   The negative point are: - The path will not be planned so far as allows the actually Navigation Leadwerks System so it is for sure not impossible that a NPC doesn't find the best way to go. This system does definiv not allow a NPC to "know" his way through the entire map. All NPCs are trying to find the best way from the position where they stay at the mooment, so never sure if/what they will find (no return of true/false that let you know the NPC found a way...) (even if this could be solved with "forcing" through a pivot where the way may be too complicated to find...) - The NPCs doen't move "round" but straight from point to point. - For sure more...? 🤔 Here is a little demo: Testing 13.08.2018 20_00_48.mp4    

Marcousik

Marcousik

Turbo Game Engine Beta Update

The Turbo Game Engine beta is updated! This will allow you to load your own maps in the new engine and see the speed difference the new renderer makes. LoadScene() has replaced the LoadMap() function, but it still loads your existing map files. To create a PBR material, insert a line into the material file that says "lightingmodel=1". Blinn-Phong is the default lighting model. The red and green channels on texture unit 2 represent metalness and roughness. You generally don't need to assign shaders to your materials. The engine will automatically select one based on what textures you have. Point and spot lights work. Directional lights do not. Setting the world skybox only affects PBR reflections and Blinn-Phong ambient lighting. No sky will be visible. Physics, scripting, particles, and terrain do not work. Variance shadow maps are in use. There are currently some problems with lines appearing at cubemap seams and some flickering pixels. Objects should always cast a shadow or they won't appear correctly with VSMs. I had to include glew.c in the project because the functions weren't being detected from the static lib. I'm not sure why. The static libraries are huge. The release build is nearly one gigabyte. But when compiled, your executable is small. #include "Leadwerks.h" using namespace Leadwerks; int main(int argc, const char *argv[]) { //Create a window auto window = CreateWindow("MyGame", 0, 0, 1280, 720); //Create a rendering context auto context = CreateContext(window); //Create the world auto world = CreateWorld(); //This only affects reflections at this time world->SetSkybox("Models/Damaged Helmet/papermill.tex"); shared_ptr<Camera> camera; auto scene = LoadScene(world, "Maps/turbotest.map"); for (auto entity : scene->entities) { if (dynamic_pointer_cast<Camera>(entity)) { camera = dynamic_pointer_cast<Camera>(entity); } } auto model = LoadModel(world, "Models/Damaged Helmet/DamagedHelmet.mdl"); model->Move(0, 1, 0); model->SetShadowMode(LIGHT_DYNAMIC, true); //Create a camera if one was not found if (camera == nullptr) { camera = CreateCamera(world); camera->Move(0, 1, -3); } //Set background color camera->SetClearColor(0.15); //Enable camera free look and hide mouse camera->SetFreeLookMode(true); window->HideMouse(); //Create a light auto light = CreateLight(world, LIGHT_POINT); light->SetShadowMode(LIGHT_DYNAMIC | LIGHT_STATIC | LIGHT_CACHED); light->SetPosition(0, 4, -4); light->SetRange(15); while (window->KeyHit(KEY_ESCAPE) == false and window->Closed() == false) { //Rotate model model->Turn(0, 0.5, 0); //Camera movement if (window->KeyDown(Key::A)) camera->Move(-0.1, 0, 0); if (window->KeyDown(Key::D)) camera->Move(0.1, 0, 0); if (window->KeyDown(Key::W)) camera->Move(0, 0, 0.1); if (window->KeyDown(Key::S)) camera->Move(0, 0, -0.1); //Update the world world->Update(); //Render the world world->Render(context); } Shutdown(); return 0; }

Josh

Josh

Next Steps

I've got the basic GI algorithm working but it needs a lot of work to be correct. I tend to do very well when the exact outcome is well-defined, but I am not as good at dealing with open-ended "artistic" programming. I may end up outsourcing the details of the GI shader to someone else, but the underlying data management is solid enough that I am not scared of it anymore. There's a lot of aspects of the design I'm not scared of anymore. We worked out smart pointers (including Lua integration), physically-based rendering, and most importantly the crazy ideas I had for the super efficient architecture work really well. At this point I think I am going to put the GI on hold, since I could play around with that endlessly, and focus on getting a new build out to the beta subscribers. We're going to just use a single skybox for ambient and specular reflections right now, and when it's ready GI and environment probes will provide that.  After that I think I will focus on the physics and navigation systems, exposing the entire API to Lua, and getting some of the outsourced work started. There's a few things I plan to farm out: Visual Studio Code Lua debugger GI details Weather system Water and clouds systems Everything else is pretty well under my control. This started out as an idea for an impossible design, but everything has fallen into place pretty neatly.

Josh

Josh

Beta Branch Updated

The beta branch has been updated. The following changes have been made: Rolled beta branch back to release version, with changes below. Added new FBX converter. Fixed Visual Studio project template debug directory. Fixed Visual Studio project template Windows Platform SDK version problem. If everything is okay with this then it will go out on the default branch soon.

Josh

Josh

Real-time Global Illumination

I finally have a cool screenshot to show you of our new real-time global illumination working. Here is a comparison screenshot showing direct lighting only: Now there are still lots of small issues to worry about. Right now I am only using a single cone trace. More cones will improve accuracy, but I think light leaking is just always going to be a fact of life with this technique. Still, the results looks great, require no precalculation, respond to environment changes, and don't require any setup. Win!

Josh

Josh

×