Stan`

All animal killing was sacrificial ?

Not that I know of. The engine only knows those two for now. The shaders are told to use UV1 for diffuse and UV2 for AOmap you cannot override this. You're limited to one material per model

We only do when we need to. You can't bake AO on a texture atlas You could bake a new texture from the Atlas but then you'll lose all the advantages of the texture atlas, about performance and reusability We use the alpha channel as the height channel That's the only case of texture combination I know. Shaders would have to be edited in order to process the others.

Also good initiative, I usually answer a lot of messages on Discord Maybe this way I can redirect some of the questions here. Although it should be in the wiki eventually.

You can experiment, but I think normal map is enough.

Should I lightpack my uv and be done with it ? I assume you mean Smart UV Project/ Lightmap Pack options of unwrapping in Blender. If that's the case, ambient occlusion is generally the only one that needs that as it's gonna be one texture per model (Although you can sometime manage to use the same texture, eg baking props with the main mesh) In general unique texture should be retexturable in photoshop for skins, so if you use lightmap or smart uv project that's literally impossible. Depends on the size of the object, sometimes diffuse is enough. Also note that you can't use AO with animated mesh and you need to bake it into the diffuse, and that normal maps only are supported with animated mesh if you add gpuskinning=true to your config file (That's also what limits the number of bones to 64, else it's 255) I'm not sure the helper bones count into that 64 I think it's only those with weights. Actually I'm not sure, can you show me an example ? Also note that Albedo is for PBR engines, and that most of the time we need to bake light information in the diffuse, because 0 A.D uses a spec/norm/diff rendering Specular is not limited to black and white, you can also use colors. Transparency used with specular and the glow material creates an inner glow (as in you won't see light on other surfaces) Transparency on normal maps creates a parallax effect. AO Maps should not have an alpha channel, although it is supported and does nothing.

Those don't use parallax, although we have that, hence the name parallax in material. Those "fancy" material use triplanar projection. From what I see it basically use the alpha channel as height as well, but instead of distorting the ground it adds little plane objects

I personally like it as well. Now we just need animations. I asked people on Social Media maybe someone will step up.

We got some feedback about them being too boxy on facebook

Yes and when not needed it's better to have no props. Each prop add drawcalls. And each drawcall means the mesh is resent for rendering. So that's 57x33k tris

Can you show me the ingame polycount and drawcalls statistics ? In atlas open up the actor viewer view and enable the option Good work. We have to be careful with the props

You need to disable TLS in the game options

@mysticjim We are waiting for some features that prevents the game from being packaged on Linux and Mac. Those features almost exclusively requires Itms to work on them for there is no one else that can do it. Unfortunately Itms is not available right now whcih delays them. Sorry for the inconvenience.

Have you tried with user.cfg instead ?

I pinged him by writing his name here. He usually checks the forums

Hello @BeanBurrito I missed you on IRC today. You have to settle the matter with @user1 who moderates the lobby.

Hello @Drogoberto You have two options. Either download a fixed bundle from Here Or in the game options in the lobby tab disable TLS. Sorry for the inconvenience...

If possible cap at 5K -7k unless you really need more

For texturing one needs to use the pers_struct.dds file. And indeed it needs more props including lamassu As for its usage it's supposed to replace the ziggurat. Feel free to take it on.

Since there would be little of them why not, now we might not need that much pixels, we'll see

Cc @Itms (Unit tests) having an idea how much coverage we have would be nice. Also having a transition guide might be nice in case we go that route.

CC @Angen

@MrLux You made a mistake in the actor file you wrote <variant frequency="1" name="Mesh"> <mesh>skeletal/europeanBison-bison_bonasus_neutralGeneric.dae</mesh> <textures> <texture file="skeletal/europeanBison-bison_bonasus_neutralGeneric.png" name="baseTex"/> </textures> </variant> instead of <variant frequency="1" name="Mesh"> <mesh>skeletal/europeanBison_bison-bonasus_neutralGeneric.dae</mesh> <textures> <texture file="skeletal/europeanBison-bison_bonasus_neutralGeneric.png" name="baseTex"/> </textures> </variant> If I were you I'd use bison_european.dae would make mistakes much easier to spot Then you added too many vertex groups, you don't need any for IKs and prop_

-------------------------------------------------------FMT bug--------------------------------------------------------------------------- The error above is actually a bug it's fixed when @s0600204 or @Itms update FMT the library being the serialization. Basically it's broken when the used locale is not present on the system. -------------------------------------------------------Thread Ripper bug--------------------------------------------------------------------------- https://github.com/0ad/0ad/blob/4b35ac33f7f30e6bb0a674a6996357a8a75cf1a3/source/lib/sysdep/arch/x86_x64/topology.cpp#L174-L193 Here is the callstack KERNELBASE.dll!76529962() Unknown KERNELBASE.dll![Frames below may be incorrect and/or missing, no symbols loaded for KERNELBASE.dll] Unknown VCRUNTIME140.dll!74e87756() Unknown msvcp140.dll!73dcec4f() Unknown [Inline Frame] pyrogenesis.exe!std::bitset<32>::_Xran() Line 486 C++ [Inline Frame] pyrogenesis.exe!std::bitset<32>::set(unsigned int) Line 266 C++ > pyrogenesis.exe!`topology::InitCpuTopology'::`5'::NumUniqueValuesInField::operator()(const topology::ApicField & apicField) Line 185 C++ pyrogenesis.exe!topology::InitCpuTopology() Line 193 C++ pyrogenesis.exe!ModuleInit(volatile int * initState, __int64(*)() init) Line 47 C++ pyrogenesis.exe!topology::NumPackages() Line 247 C++ pyrogenesis.exe!RunHardwareDetection() Line 307 C++ pyrogenesis.exe!InitGraphics(const CmdLineArgs & args, int flags, const std::vector<CStr8,std::allocator<CStr8>> & installedMods) Line 1001 C++ pyrogenesis.exe!AtlasMessage::fInitGraphics(AtlasMessage::mInitGraphics * msg) Line 90 C++ pyrogenesis.exe!AtlasMessage::fInitGraphics_wrapper(AtlasMessage::IMessage * msg) Line 84 C++ pyrogenesis.exe!RunEngine(void * data) Line 173 C++ pyrogenesis.exe!thread_start(void * param) Line 624 C++ ucrtbase.dll!7701505f() Unknown kernel32.dll!7694f989() Unknown ntdll.dll!77da74a4() Unknown ntdll.dll!77da7474() Unknown The bug is this one https://trac.wildfiregames.com/ticket/5412 @Itms submitted a fix https://code.wildfiregames.com/D1789 @OptimusShepard can you make another zip for @Froschkoenig84 to try?

Our problem (On windows at least) is that we trusted the hardware and I guess janwas made educated guesses about it which has worked until AMD decided to mess things up. Also there are two different bugs. Hardware detection which is probably too precise for its own good and for our needs, and the timer code. AFAIK we only use the former to detect the timer then use a custom function for TSC or with my patch QPC which is part of the windows API. I chatted a bit with @wraitii on the SIMD changes and I believe the discrepancy on Linux vs Windows is due to the fact some optmizations are disabled on MSVC while they are "on" on Linux.