Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Mar 2011
Online Last Active Today, 04:24 AM

Topics I've Started

normal / tangent differences when baked for Unreal vs Unity?

17 August 2015 - 03:21 AM

I have finished a "speed sculpt" in 3D Coat last week, and after a not-so-speedy retopo (I always underestimate the effort that goes into a good retopo smile.png ), I baked my highpoly voxel sculpt to the low poly mesh in  3D Coat and started painting. I was actually positively surprised to find almost zero baking errors on my first try, which went against my expieriences with 3D Coat.


What I didn't realize at the time was that the settings where set to "Unreal Engine preset". I did this sculpt in part to test out the new 3D Coat 4.5 (which has some amazing improvements btw... PBR FTW), so of course I lost all my settings from the prior version.


Now, when I realized that, I immidiatly exported the halfpainted model to .obj and tried import to Unity, which currently is my engine of choice. Even before the import I could see that the normal map looked different then what I was used to (tangent space normal maps in Unity usually have "flat colors" for flat areas... this one, optimized for Unreal engine, had a gradient over flat areas).


Needless to say the model has weird shading in Unity. Though interestingly, the missing baking errors are still apparent, while a second model where I tried to remove baking errors for an hour with additional gemometry ans shifting vertices still has lots of it, even though the shading of the normal map is now correct (as it has been baked with the options set to "Unity preset").




This might be a very specific question about very specific tools and engines, but really behind it are more general questions:


Why do normal maps baked for Unreal look so different to the ones baked for Unity? Why do the models tangents/normals themselves seem different? And why the heck do I get a whole lot more baking errors when baking for Unity, when the bake for Unreal seems to be quite fine without a lot of tweaking? Is this a 3D Coat problem, or is the Unity model importer to blame (tried obj and fbx, same errors on the model)?



I tried for hours to get the low-error baking result from the Unreal preset with tangent space maps optimized for unity, but that doesn't seem to work. My next step is to download Unreal 4 (which I have planned to do for ages by now, but never found the time) and see if I can import the 3D Coat baked model to that engine without problems (and with the same low baking error result that the painting room in 3D Coat indicates)... if that works, I definitely have to think about switching engines, because baking errors have been a MAJOR PAIN IN THE *** for a long time now when importing to unity.

I know from other engines that their importers had less struggles with 3D Coat exported obj files than Unity, so if Unreal 4 does the same painless import, it might just become my new engine of choice.

Gonna miss the asset store though....





Spent yesterday evening downloading and installing UE 4, and had a first test run. I am quite impressed so far. Most interesting fact ist that indeed, I was able to import the model as FBX without any of the baking errors that plague the version of the model built for Unity. Really cool, a clear 1:0 for Unreal. Still missing all my third party components and fighting with the editor, but saving hours of bake correction time on each model is massive for me.


Anyway, question is still valid: why? Why the different looking normal map, and why does it have such an influence?

Unity 5: DLL naming conflict with same names even if in different directories

23 March 2015 - 05:25 AM

 Im in the process of migrating my Unity 4 Project to Unity 5... and while I expected a lot of pain doing that (seeing how much of the API changed), I wasn't prepared for this particular problem.


Now I know that I might need to contact Unity about this problem, but a) I don't really trust Unity user support too much, they are fine guys and are usually very helpful, but seem to be usually COMPLETELY drowned in work (most of the time, I get no response), and b) same can be said about the Unity forums. I DID start a thread in the Unity forums, no response for a week does not make me confident that I will get any help in a timely manner there.


And as there are a lot of fellow unity users on this forum, I will just try my luck here. Maybe someone ran into the same problem before and was able to fix it?


Here is what I wrote on the unity forums:




I just imported my Unity 4.3 Project into my new Unity 5 installation. I expected many errors to fix, but some of them really make me scratch my head, no less as they are affecting 3rd party dev assets.

This is especially weird: I have had the Logitech SDK in my project for a long time now to use DirectInput for the XBOX Controllers (So I could get rumble to work). Now, this has always worked just fine in Unity 4, with no error whatssoever. I haven't changed anything before or after the import to Unity 5, still there are now new errors popping up in the console:

Multiple plugins with the same name 'logitechlcd' (found at 'Assets/Logitech SDK/Lib/LCD Lib/x64/LogitechLcd.dll' and 'Assets/Logitech SDK/Lib/LCD Lib/x86/LogitechLcd.dll'). That means one or more plugins are set to be compatible with Editor. Only one plugin at the time can be used by Editor.

Could anyone help me what is the problem here? I read that having multiple dlls share the same name in the same folder could be a problem, but these seem to be properly put into their own folder to distinguish between x86 and x64 versions, even if the GUID wouldn't be correctly set.

Anyone got the Logitech SDK already to work with Unity 5? What did you do? Do I need to rip it out of the project and re-import the SDK?

Thanks in advance for any help!


EDIT: just to be clear, this problem affects ALL plugin dlls, not just the logitech ones! I get such errors all over the place.
Seems Unity 5 cannot handle DLLs with the same name, even if they are in different folders. I don't think this is expected behaviour?



Now, to describe the problem in a more detailled and precise form:


Since starting to use Unity 5, it seems DLLs contained in different directories but sharing the same name started conflicting with each other and throwing errors as seen above in my Unity forum post.

This affects ALL DLLs, not just the LogitechSDK ones! This same setup worked fine in Unity 4, and according to the documentation, should also work fine.


Now, it could be that Unity somehow changed the naming rules for DLLs (which I would be a little bit puzzled about, as it would mean lots of third party asset providers had to redo their DLL naming for no good reason), or that this is just a teething problem of Unity 5. I couldn't find a thread on that particular problem in the Unity forum and on google, but I cannot be the only one facing this problem.


I got this problem when migrating my old Unity 4 project to Unity 5, and I get the same problem when creating a new Unity 5 project, and import the LigtechSDK into it. I get the same errors for any other Unity package that use multiple DLLs with the same name in different dirs.


Anyone got the same problem and found a way to fix it? Anyone got any idea what I could try before I contact the thirdparty asset providers and tell them to fix their naming?



Thanks for any help



Quicktime Events - why are they so widespread still? A question and a rant.

28 November 2014 - 04:50 PM

Well, this thread is a mixture of venting some anger and really looking for opinions as I am quite confused at the moment...


Quick backstory, I try to make it short:


After having rediscovered my love for Castlevania thanks to the PS1 emulation console version of Symphony of the night on my PS3 (I finally gave in, as I could only play the japanese version in '97), and having aquired the classical Super Castlevania for my SNES, I figured I would give newer Castlevanias a chance again (Lament of sorrow on the PS2 made me stop playing Castlevania for almost 10 years... it was just so boring and crap IMO)...


Having read lots of good reviews of Lords of Shadows, I choose to use this years Steam Sale to get the PC Version cheap.


Now when I fired the game up, I was at first really hyped... this game looked good! And the story sounded dark and brooding, as in the good old days.


First downer was the really linear level design, but well... that is kinda classical. SotN is rather exceptional here for a Castlevania...



What I was NOT prepared for was the extremly annoying amount of quicktime events! Granted, I usually avoid brawlers like god of war (and I am a little bit pissed Castlevania has evolved into another such brawler), but as if Quicktime events in 2010 wouldn't be bad enough, the developers filled the game to the brim with it! No boss battle without annoying Quicktime Fiesta... often you don't even use your whip anymore besides swinging up a ledge, instead you watch the Boss battle as a movie waiting for that random button press to flash up.



Now, I know tastes differ, but seeing how gamers usually despise quicktime events, what could make a developer force players through lengthy quicktime events when the whole history of games show that QT Events are NOT needed at all for a good game.


I totally understand that the devs where not happy anymore to have players whip holes in walls and uproot trees with throwing knives... it looked okay in pixely 2D, but would look just funny in HD 3D (Still, even then I am not 100% I need more than a short hint what I need to do, instead of the constant "Press X Now!").


But Boss battles? Common! I don't care how spectacularly big and cool your boss is, if it looks off whipping the beast to death, how about giving players the chance to just jump up to the beasty and whip his weakspot, instead of forcing him to climb and jump with random QT button mashing galore?


Puzzles me really. Cut the cutscenes to the minimum (a good story does not need cutscenes), leave out the QT crap, and concentrate on interesting, non-linear levels. Without invisible walls and stuff. And just let the player decide how he tackles the boss, as long as he is able to hit the weakspots. This could have been a good game, but I don't think I will finish this QT helll.



TL; DR (yes, I failed with the short part):

Why do devs still choose QT Events over better forms of game design? Do they think players expect a (not so) interactive movie? Do they think its the only way to make things look good when the best free running system fails because the climbing target is moving?

Or does it just relieve them from proper game and level design, because they can skip a complex free running system, and make an extremly simple collision handling, and just force the player into a narrow corridor and binary (hit the button or die) choices?


Is there a different reason I am ignorant to?

Marvelous Designer: Opinions? Workflow Advices?

23 September 2014 - 10:10 AM

I recently started playing around with the tool Marvelous Designer...  for anyone that does not know the tool (and is to lazy to follow the link... no, I am not paid by anyone to make shameless ads, the link is just there as explanation for the uninitiated smile.png )


I have to say I am highly impressed and skeptical at the same time. The cloth physics engine is impressive, and for simple clothing you get good results quickly.

I am a little dissappointed about the performance of the tool though, first I thought that it was strange that all the vids I have seen of somebody presenting their virtual clothing with an animation from MD had hacky animations with low FPS... surely not all of these people could be using a toaster for a PC?

Then I tried it on my own Workstation, which might have Gamer Hardware that is now ageing being 3 years old, but was top of the crop 3 years back and is still very strong today: a 6 core i7 with hyperthreading, a GTX 580 and 24G of RAM should give MD enough power for all its cloth physics black magic.

Yet even with my PC, things get really slow as soon as I start to reduce the Particle Distance, which seems to be MD language for Mesh Resolution.

Then there is the whole thing with the cloth pattern creation. To say the whole thing is giving me headaches is an understatement. I have no idea about cloth sewing in RL, so while creating a basic skirt or shirt might be easy in MD, as soon as it gets more complicated, I start to struggle.


while I really like the idea of not having to sculpt all the folds in my clothing items by hand, getting down the basic shape of the clothing and then adding the details seems to be really painful with the limited toolset MD currently is equipped with.



So my question to anyone that has already tried the tool, or might even be a pro user: What is your opinion on it? Is it worth its asking price, does it REALLY help with efficiently sculpting clothing items for game characters, or is it in the end just saving time on one end while adding headaches at another?


Also, as a total newbie, I am struggling with some things:


1) the only symmetry I found was "copy as symmetrical", which means you will have a seam in the middle. Woot? It just can't be that there is no symmetry tool available for creating clothing pattern patches in a symmetrical fashion without a seam in the middle. Did I miss something?


2) Is there a function to import a Pattern, or at least a image file as a rough pattern guide to draw over? I am thinking about creating the basic shapes in 3D Coat, unwrapping them and then using the UV set as cloth pattern in MD. I am much more proficient with Voxmodelling than with creating clothing patterns.


3) Did anyone found the reason for the bad performance of MD? Is it just missing any kind of Multithreading or GPGPU Acceleration (which I suspect it is)... is there an option I missed that leads to the bad performance on my machine?



I am aware that I might need to take my questions to the MD Forum for a better response, I just wanted to see if there some users here have made any expierience with the tool... usually you will not find the highly critical users on the message board of the company creating a software itself. And there seems to be a big hype around MD which I struggle to fully understand, so to speak.

publishing a game to desura and steam - possible?

03 June 2013 - 04:01 AM



I'm a total newbie when it comes to self publishing games to digital platforms like desura and steam (being nothing than a wanna-be-Indie hobby dev at the moment) ...


Having heard not much good things about an Indies chances to get through the steam green light process without help I wonder, is there anything stopping you from publishing your game to other services like desura (no idea if this would be easier to get on), and only start the green light process when you found a healthy bunch of customers and fans there?

I would imagine getting greenlighted can only get easier the more well known your game is to the public, so releasing it somewhere else before steam sounds like a good idea to me.


Thanks in advance for any information