So i've modeled an anatomic base to get the futur clothes and accessories coherent. Most of it can be extracted directly from the mesh.
Since it's my very first model I choosed what i was the most comfortable with, a human body; Also because i'm not too confident yet to start an outfit from scratch. It's like having a sketche of a body before adding the outfit when you're not too sure. I'm not sure yet of the outfit i'd like to model but something really basic for now; To later use it as a base aswell to model more declination.


Note that the backview (above right) is smoothed. The hands are the low poly base of what will be proposed to the team later for the first person POV.

The ear is not really well defined yet, that's probably something i'll have a look into later.

July 4,2014

For episode 6 I removed all of the reflective entities and post processing volumes.



In some ways I prefer the simplicity of UDK when it comes to the basics of texture work and rendering. Granted it's not as hi tech as UE4 but as far as moving from Radiant to the UE4 editor goes the connection between what you know and what you have to do to get the same results is a bit more complicated.

Urban Terror's art as far as look and feel goes is still very much relevant and is something that I would at least would like to preserve as to the idea of being able to replace an old engine, in much needed repair, with something that is fixed based on the needs of those who play our game.

With the release of UE 4.3 on the horizon it seems to me that Unreal 4 is not a completed engine and in much the same way we are trying to keep our community up to date as to the in progress UE4 Subscription, I'll call UE4S to give it a name, is is very much a work in progress intended for first adopters to begin the process of developing their own titles or to convert their current works over to the new platform. How you think something should work that does not is usually a case of it's not been implemented, or turned on as an accessible feature, so as they are made available in an up date what you have done already can be impacted by those additions.

To put it into simpler terms UE4 is not consumer ready and if you are interested in getting involved be prepared to have things go a bit sideways on you from time to time.

I would have to say the biggest change that is a blanket that covers it all is in the change from the basic diffused texture system to physics based materials. Physics based materials is very nice in that it can produce cutting edge results, as well suspect a performance boost with out quality loss, but keeping the almost color neutral look is a bit of a chore.

With a diffused texture what you see is what you get and to get the same result with a physics based material you have to add values to the materiel tree that tells the engine that it's just a simple texture with out properties else the result tends to behave in an unpredictable manner.

For example a reflectivity volume maybe required if you have an object made of metal and the material applied needs to have a value applied as to how the surface reacts with the volume. The result is surrounding materials that do not have this value, IE a single channel diffused texture, it can react to the addition in strange ways as to being something you think is broken. A surface that is suppose to be brick reflects like a polished floor for example.

The best I can figure at the moment is to get the results with out the side trips to fix things that goes bump in the night is to turn everything off and to work the design in passes as compared to the more fit to finish pathway most might be use to working with Radiant.

With Radiant one would work on a single element of their design, compile and test run it, and if it checks out as to intended result one would go onto the next addition.

With UE4 the pathway is more it has to look bad before it looks good other wise you can land up wasting a lot of time to get that fit to finish look. Following the old pathway you could work an element to the point that it looks good and consider to be done then add the next with the same approach and what you thought was done now looks bad due to the changing of what should be a set value.


Here is a video where Epic explains what I'm saying. Takes bit to get to the point as to why the fit to finish approach is not a good idea.



The over all impression that I'm getting is to get that AAA look it takes a lot of individual skills even working on a simple environment who understand how all the nuts and bolts interact with one another and if you are going it alone then the process outlined in this video is the best approach as you can land up constantly fighting with things you don't know that does not have the focus or your attention to that detail.

At this stage in the game the best option as to work in progress is to go back to pass one as describe in the Intro to Level Design and finish off the environment at the base level rather than attempting to continue with the fit to finish approach, familiar in Radiant.

I'm not going to rip the material work out but expect things to look worst as I figure out what needs to be done.

It all started in March of 2012. At this time I was actively working on Urban Terror HD on things such as improvements for the Match Mode and a new game mode called Jump Mode.
We were really worried about the health of Urban Terror and its community. We could see the number of players falling from day to day.

The community was absolutely in need for good news about HD and our negotiations with id Software to get a contract were not going anywhere. We were told for several years that we would have a (relatively) cheap contract for a multi-platform game and what we got after the long wait was a two-years-only Windows-only expensive and restrictive contract. We couldn't sign it.

We were stuck. We couldn't work on our HD engine anymore and we couldn't release new alpha versions. It's been a really hard time for the whole Frozen Sand team because we understood we were going to throw away all the work done on HD. This bad news from id Software and the decreasing amount of players on 4.1 killed the motivation of everyone in the team.

From my coder side of view I didn't want to throw away all the work done on HD and I knew we were able to port some parts of it to the version 4.x of the game. This is when the idea of doing a 4.2 version began. I suggested it to the team and everyone was ok but I had to handle doing pretty much everything code-side because there was no other active codebase developer at this time.

I had a big problem though. The source code of Urban Terror 4.1 had been lost years ago and all I got was an old-4.2 mod code that was very experimental in a lot of areas. It had to be debugged and cleaned up a bit in order to be used as a good start. It took me a while to find and fix hundreds of bugs with the help of the Quality Assurance team. Then I started adding improvements and bug fixes done on HD and at the end the changelog of 4.2.001 was quite big and I started being satisfied with it.

In May of 2012 we were close to the date of the French LAN of Urban Terror in Paris and we thought it would be great to introduce it here and let everyone test it to gather more feedback. The day of my birthday (yay!) we officially announced for the first time Urban Terror 4.2 and its changelog. I had only a few days to prepare a pack of 4.2 for the LAN with a few more last minute fixes. We were all really excited about this event.

In June I went to Paris with holblin and other volunteers from the French Community staff and we installed 4.2 on more than 80 computers for the LAN. I was in charge of the dedicated servers during the whole event (eek!) so I had to install and manage up to 8 servers.
It was a cool event despite some crappy computers on which people had FPS drops. A large majority of players were really cool and I gathered more feedback than I could ever think.

The LAN convinced me to continue the development of 4.2 after its first release, but we needed an easier way to update the game. I started working on an Updater which needed to be multi-platform as well as available for server administrators. You cannot imagine how hard it is to make it work for everyone on every platform. It was a HUGE challenge and despite it's bugs on some machines I'm still really happy with it. At the time of writing this blog entry, the Updater has been downloaded more than 500,000 times on the official website. I had to learn a new programming language and a new framework to develop the Updater so I have no regrets at all. Shout-out to Kalish for the great Urban Terror-themed design for it. By the way, it is open-source so do not hesitate to help fix bugs if you want. :)

Just before we dropped the development of HD on quake's engine, Kalish was working hard on the Authentication System. I thought it would be great to "beta test" it and asked him if I could port his code in 4.2. He was ok (it took me a while to convince him though!! :P) and he started helping me do it. We ended up working literally days and nights on it in June and July.

We all started getting really excited because the LAN event was a success and the authentication system and the Updater were working after weeks of intense work. It was going to be our first release since 2007 or 5 years! I had stopped all my other personal projects for months to get it done, I worked on it every single day for 4 months and I couldn't delay it anymore, I wanted it to be released. We wanted it to be released. This is when we made a huge mistake. We announced a release date. We should NOT have done that because it put a huge pressure on us from the community, and we were not ready. The game needed to be tested a lot more by the QA team, the authentication system needed more work and Kalish asked us to delay the release but I didn't listen. I wanted it out now. I didn't want the community to be disappointed by delaying the release.

This was a freaking mistake. The release was a disaster. There were bugs with the hitmesh that we didn't catch with the QA team as well as a huge bug in the authentication server. If I could go back in time I would slap myself for being hasty and I would postpone the release.

Anyway, I don't have a time machine (yet). :) So we had to move forward. It took Kalish one month of hard work to fix all the bugs with the authentication server. Today I still feel bad for doing this to him because he had even put aside his IRL work to fix the auth server.

Fortunately more awesome coders and artists stepped in to immensely improve 4.2 over time and I think I can now say that I'm proud of what 4.2 has become. I learned so much from my mistakes. Now I am always the guy at FS saying "no no don't release now, test it one more week!". :P I guess it taught me to be more patient and wise and it will be useful when the time of releasing Urban Terror HD will come.

There is so much more to say but I think it's enough for this blog post. Do not hesitate to tell me if you want more "behind the scenes" articles!

---

Note: this is an x-post from my personal blog.

If you want to read more from me, you can visit my website and follow me on Twitter.

There's not too much happening on uptown at the moment but I thought I'll show you a screenshot anyway. I'm still in the process of rebuilding all the geometry. There's no textures yet, no fancy lighting, just grey buildings. You can compare the current buildings to the old 4.x ones. I added some more detail especially around the windows and trims of the buildings. I also adjusted the scale of the windows and buildings because some of it was really off. Notice how flat the two buildings on the left look in the old version. There are a lot more things off scale in Uptown and some very unrealistic stuff that I will elaborate on in a future blog entry.

Old:

New:

That's it for now,

Have a happy day! :)

Okay, the title is not self inflating enough, but it is ment sincerarly! In the modern age games are not mearly their game content, but also their community and backend tools that tie everything together.


Here at Frozensand we take the "Back End" stuff very seriosly! We have designed our our CMS for web services called FS-CMS which is a cluster aware, self provisioning, cluster based system. Now you can simply use Steam, and we indend on doing so for "HD", however, there is more to providing a game loving experience than just "Nabbing" the tools provided.

In my last blog you will see work of me porting our inferstructures to OVH RunAbove to provide the compute and storage power required for a truely global and "User Limiteless" experience. Nothing worse than having a vival game and not being able to soak that load up when you have traffic peaks!

I effectionally call this "FU Steam Syndrome" :D ...

In the coming weeks i will be introducting people to my plans on UrT-HD-API (for Community Devs to intergrate with our datas for HD) and more on RunAbove and how FS-CMS Scales its self on the current load being drawn of it!

June 23,2014

Urban Terror HD - Working with Power Tools ep2 Player Models

In this episode of of WPT we introduce you all to our current design pathway for future player models coming for Urban Terror HD and outline our current reasons for doing so.



With out a doubt player model development is a time consuming process when coming at it all from a crafting direction but after extensive examination procedural design has reached the point that crafting can still be involved along with the benefit of supplying a large volume of different and unique player models in short order.

The procedural approach will work well for us to divide the work load where anyone on the team could build from scratch if they wish by using the procedural pipeline in place and could add their work to the line up with out the technical assistance of another developer with the necessary skills to get the result into the game.

By far this is a must do as it's always been the case that to do or get anything into the game usually involved the assistance of another who was not always available or working on something else of more importance that tended to stall feature additions and has at times been forgotten.

Using this approach a player model can be designed in hand, as a primitive so to speak with our ideals that one day a player could log into a server and never see the same player model twice.

I have been working with my plant textures creating materials in UE4 for them. I have several colours of a Dutch iris as well as several other plants that I want to use. When we were exploring UDK for UE3 HappyDay found a tutorial on using the RGB channels of a diffuse texture as the mask for a transparency instead of using an alpha channel in the texture. This saves memory because the mask texture is saved as a DXT1 instead of the more expensive DXT5. In UE4 you can create a material using parameters for everything from the base texture to the mask texture so you can make one parent and an unlimited number of instances from it for all of your transparent materials. Thanks to HappyDay for teaching me how to add an If statement for the mask.

First import your textures and then create the parent material. I chose my Dutch Iris as the parent. I created a simple material with blend mode "masked" so I could add an opacity mask. This parent has a vector parameter for the subsurface colour (the light yellow square), a couple of scalars for metallic and roughness that aren't being used atm (they are there for future use if needed) and an opacity mask with an if statement for its rgb channels. B is a constant set on 2. By changing the value of the scalar connected to input A I can assign which RGB channel the material should use. By using TextureSampleParameter2D instead of just a simple TextureSample I can change the base texture and the mask texture.

The next image is an instance created from my parent material. As you can see the material editor looks different. In this example I have changed only the base texture.

In the following image I have not only changed the base texture to a different type of plant but also the mask's channel has been changed to 3 which is the blue channel.

In the next example I have changed the texture used for the mask as well as the base texture. This is still an instance of the first parent.

One of the great time saving features of working with instances is if you update the parent it is propagated to all of the children. I decided that it would be handy to be able to change the tint of a base texture so I added a VectorParameter to the base colour path.

Now I can change the tint of any of the base textures. You can see that the editor has added the new parameter to the menu of functions I can modify.

This technique not only saves time but it also saves memory and improves performance.

June 22,2014

OK so I finally got my microphone back and my clean from scratch reinstall of Windows 7 to behave the way I want so I'll be adding some commentary to my YouTube videos and get into the 21st century.



If you think about blogs are so 2010 and best serves the “agenda” but for a video game I don't think it unreasonable that people what to see stuff and not just read about it. I could say we are doing this that and the other thing but to quote Barbie, and may others, with out video or screen shots it did not happen.

For me of course it's yet another opportunity to have fun, or be funny, which is what membership on this team is all about. By far the single problem of keeping people working on the project is at some point the shiny wears off and becomes more like work than something that you “enjoy” doing on your free time but as a content creator there is “always” something fun to work on if you can ignore the handful of the hardcore who are just out to bust your nut.

Sooooooo

To keep things in one place I'm going to call the series Urban Terror HD – Working with Power Tools which will be informal video blogs, with commentary, and if you all what to jump on the band wagon away with your questions and I'll toss in a Q&A while I ramble on.

While skinning the hair I ran into a bit of a problem with the seams in the uvw unwrap that made it hard to match the hair as you can see in the image below.

My solution was to change the uvw unwrap and move the bit that was at the top of the neck to the same map as the head so it is now attached to the head's polygons and the only seam I have to deal with is the centre back seam which is much easier to hide. The green lines are the seams.

After moving the pieces highlighted in red it was much easier to skin the hair.

Recently I went into the capitol for a day of geekery with our hosting provider here at FS. For those who don't know that is OVH. The are currently going around the world introducing clients to their products. You can see the event i attended here.

After much talking a free bar and then more talking with the nice people at OVH I have the priveldge of being invited to test a new Brand/Product from OVH called RunAbove.



RunAbove is OVH's all new Cloud OpenStack solution. For those who don't know what that is ... google it :). For those who do, these are exciting times as OVH enters the by the hour billing. They do not disapoint either!

In the coming week I will be migrating our inferstructures over to RunAbove. One of the big differences is that the VMs them selfs will have a mix of Compute or Memory Nodes, each of which have a switching connection of 10GBit/s. Yes, we can burst to that if we need to!!

It's super exciting times, and i would like to take the time to thank our new partners over at RunAbove / OVH for making this possible!!