<?xml version="1.0" encoding="UTF-8"?>
<rss version="0.91">
<channel>
	<title>Resistance Force Blog &amp; News</title>
	<link>http://www.resistanceforce.com/blog</link>
	<description>Development blog</description>
	<language>en</language>

<item>
	<link>http://www.resistanceforce.com/blog/20180919-210142?rss=1</link> 
	<title>20180919-210142</title> 
	<description>The work on modeller is going well. There was a lot of &quot;invisible&quot; work, like various fixes for geometry processing and proper handling of float inaccuracies in the clipping code. I haven't found any formulas for spheres when using 3D Bézier surfaces so had to iteratively find a good approximation. Apparently everyone doing 3D just uses NURBS surfaces instead, these are more complex, both to the user and the computer. Something that I want to avoid.

Using Bézier curves is pretty easy in 2D case, there are few simple rules to make the curves always smooth. In 3D it's more complicated, especially when you can stitch different patches together or parts of itself (like is the case with the sphere) creating more complex topologies. But I have figured out how to handle it with a simple constraint system.

Also designed how the texturing will work, again in 3D everything is more complicated. But have figured out all the necessary steps to make it work in a straigthforward way for both the user and the computer. The surface patches are providing nice automatic UVs. However the texels are non-linearly spaced in regard to 3D positions. I'm incorporating this into the internal workflow, basically using a very high resolution texture for storage and make the various paint tools to work with this non-linearity.

This texture handling will use own &quot;database&quot; approach to it, including on-disk cache for texture tiles to allow editing arbitrary sized textures. All the textures multiplied with multiple layers and different &quot;channels&quot; (albedo, heightmap, transparency and specular) will require to work with a lot of data. This is pretty much the same setup as in graphics editors such as GIMP.

The internal textures will be then rendered into desired levels of details. This applies also to the modeller usage, where you will just see some lower resolution view of the internal textures, but still editing at the full resolution (similar to zoom function in graphics editors).

http://video.resistanceforce.com/blog/20180919-simple-editing.mp4</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/20180821-074841?rss=1</link> 
	<title>20180821-074841</title> 
	<description>Finished the GPU rendering part, now it renders the exact same output as the software renderer.

The general idea is that most of the effects (lights, ambient occlusion, some material properties) will be baked into static textures unique to the surfaces. The map file will contain all the texture layers used (including both generated projected textures and direct per-surface textures where needed) and the engine will be able to regenerate them as needed.

Same with the geometry, where the input will be various surface patches and the result will be nicely blended single mesh divided into a grid that will allow to process and update parts of the map as needed. Each cell in a grid will be generated in multiple levels of detail to aid rendering of more distant cells.

I've been inspired a bit by the various voxel engines, utilizing both the coarse approach (the grid that the geometry will be splitted into) and also on a micro level with the geometry processing to allow blending between shapes and average out too small geometric details as they would produce aliasing otherwise (putting the detail into a normalmap instead). This is similar to mipmapping for textures but for geometry. This will basically tie the level of detail of geometry and textures. The algorithm will not use actual voxels, just processing in a way that will produce similar result.

Now that I have all the needed pieces done I can work on the actual modeller based on Bézier surface patches.</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/20180811-213506?rss=1</link> 
	<title>20180811-213506</title> 
	<description>Finished all the needed primitives for software renderer, next stop: adding 3D rendering on GPU so I can switch back to use mostly GPU for developing.

I'm keeping the CPU and GPU renderers in synchronization, the 2D rendering is already fully done and produces an exact output in both the CPU and GPU renderers. I have decided to use quite simple material &quot;shaders&quot;, mostly relying on cubemaps to provide most material effects (this includes glass materials, glossy surfaces, general lighting on dynamic models, etc.). With the right combinations of inputs one can do wonders with such a simple setup :)

I've found that with proper filtering (actually during cubemap generation, no expensive operations needed during rendering) one can have cubemaps without any seams and actually the cubemaps can be really tiny for most glossy materials. This enabled to use just world-space normal maps and instead creating such cubemaps dynamically to provide the lighting for the dynamic objects (instead of computing the lights per-pixel).

The static world will use pre-generated lighting, mostly relying on raytraced ambient occlusion. I plan to do global illumination effects by manually placing extra lights, as I think it will be better than the automatic approach I've used in the previous engine. Due to the need to process lighting in HDR it tended to have washed out colors and basically was the same as a pure ambient occlusion. This will enable more artistic approach to the thing.

Speaking of HDR, similarly to the previous engine, it will use various fake HDR approaches as well. I don't like how with HDR you can't easily control the resulting image, also with the tonemapping operators the colors tend to be washed out and there are over and under exposures. I always felt that the HDR rendering simulates more a camera than a human vision. Unless you're observing extreme light conditions you generally do not see over and under exposures.</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/20180806-130821?rss=1</link> 
	<title>20180806-130821</title> 
	<description>Created a better video recording approach by just recording the drawing primitives at the engine level. This allows to create nice 60 FPS videos from now on :)

The following video shows the GUI system, it is scalable without losing crispness (in fact it uses subpixel high quality antialiasing everywhere) so very well suited for productivity with the editor. The 2D rendering is shown in software renderer but a high-performance GPU rendering also exists that can render complex 2D shapes with the same 64x subpixel antialiasing.

The rich text panel is something that is not as optimized currently. I've ported it from some other project of mine because I thought it could be useful for some things (like integrated help in the editor). The majority of slowdown is because it redraws everything needlessly on change and also because all the text rendering is done by rendering 2D shapes :) This is because it uses subpixel positioning so it's not as easy to cache to images. For normal usage in GUI it performs well (esp. on the GPU version).

http://video.resistanceforce.com/blog/20180806-gui-system.mp4</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/the-last-few-years-of-development?rss=1</link> 
	<title>The last few years of development (2018/08/06)</title> 
	<description>Hello again after a long time :) I would like to summarize what happened in the past years of Resistance Force development.</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/new-alpha-version-available-build-17?rss=1</link> 
	<title>New alpha version available (build #17) (2012/12/08)</title> 
	<description>New version is available, adding dynamic shadows to point lights, weapon recoil, updates to Central map and other improvements and bug fixes.</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/new-alpha-version-available-build-16?rss=1</link> 
	<title>New alpha version available (build #16) (2012/11/14)</title> 
	<description>New version is available, introducing three new maps, improved leaning, server browser and other improvements and bug fixes.</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/resistance-force-map-editor-is-now-available?rss=1</link> 
	<title>Resistance Force Map Editor is now available (2011/12/10)</title> 
	<description>Map editor is now available for pre-orderers. It contains two tools: the map editor itself and composite texture editor. Both are available for all three platforms (Windows, Linux, Mac OS X).</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/new-alpha-version-available-build-15?rss=1</link> 
	<title>New alpha version available (build #15) (2010/12/30)</title> 
	<description>New version is available, most notable changes are: improved player model,
added bullet spread and multiple damage zones to players, moved ragdoll
computation from client to server ...</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/new-alpha-version-available-build-14?rss=1</link> 
	<title>New alpha version available (build #14) (2010/06/11)</title> 
	<description>New version is available, most work went into adding major features into
the engine (static meshes, composite texture, material system, normalmaps)
and optimizations. On the game side the current map was enhanced,
initial set of detail meshes was added and there is a new gun available.</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/new-technology-composite-texture?rss=1</link> 
	<title>New technology: composite texture (2010/03/06)</title> 
	<description>It has been some time since last blog activity, more than it should be. It has two main reasons. The one is that I've been distracted with unrelated matters more than usual. The second is that I'm working on a new technology for Resistance Force's engine: something I called the composite texture. ...</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/wysiwyg-in-resistance-force?rss=1</link> 
	<title>WYSIWYG in Resistance Force (2010/01/07)</title> 
	<description>WYSIWYG (What You See Is What You Get) is a major feature of Resistance Force ...</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/new-alpha-version-available-build-13?rss=1</link> 
	<title>New alpha version available (build #13) (2010/01/01)</title> 
	<description>New version is available: it brings explosive grenades to the arsenal among with many bug fixes and small features...</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/evolution-of-the-game-part-1?rss=1</link> 
	<title>Evolution of the game (part 1) (2009/12/13)</title> 
	<description>Today I was browsing through my screenshot archive and stumbled upon old internal screenshots from early development versions of the game...</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/how-to-help-development-voice-actor-needed?rss=1</link> 
	<title>How to help development &lt;del&gt;(voice actor needed)&lt;/del&gt; (2009/12/01)</title> 
	<description>Since the release of alpha version some people asked if I need help with
development, mainly with modelling, mapping ...</description> 
</item>

<item>
	<link>http://www.resistanceforce.com/blog/public-alpha-version-released?rss=1</link> 
	<title>Public alpha version released (2009/11/19)</title> 
	<description>Public alpha version of this game was just released, also the website is now open. This game is in development ...</description> 
</item>

</channel>
</rss>
