Jump to content

Xycaleth

Members
  • Posts

    1,458
  • Joined

  • Last visited

Posts posted by Xycaleth

  1. @@Xycaleth - perhaps it is a coordinate system thing between MD3 and GLM? The MD3 specs state:

     

    Also, aren't MD3 vertices/normals defined in a left-handed 3-space coordinate system and GLM is right-handed?

     

    The result of converting the spherical coordinates to a 3-vector will be in the Q3 coordinate space, and will be the same space as the normals stored in the GLM files. That shouldn't be the issue.

     

     

    The only difference I can see is that MD3 has tangent, normal and bitangent in a struct. GLM has normals in a struct, but not tangent or bitangent.

     

    Also my VS likes to point to MDR code when finding the definition of normal, even though it is coded to point to the GLM one.

     

    The bitangent and tangent vectors aren't stored in memory for GLM models because the CPU never needs to do calculations on them. They're stored entirely on the GPU. I think the same thing can happen for the MD3 models too but it just hasn't been done.

     

    Do the normals look correct if you turn off normal mapping? That would rule out the normals being the problem since the bitangents and tangents are only used when normal mapping is enabled. If the problem is still there, it could be an issue with the exporter?

    Tempust85 likes this
  2. I'm not sure why the normals would be different. The bitangent and tangent are calculated at load time (when the models are loaded). Neither have them stored in the file itself.

     

    Here's the bitangent/tangent code for MD3s:

    https://github.com/DT85/OpenDF2/blob/rend2-sp/code/rd-gl2/tr_model.cpp#L714

     

    GLM here:

    https://github.com/DT85/OpenDF2/blob/rend2-sp/code/rd-gl2/tr_ghoul2.cpp#L3607

     

    They look pretty much the same to me at a quick glance. The code is split up a bit more than the GLM version.

     

    Maybe there's something I'm missing.

     

    EDIT: It's more likely the tangent/bitangent calculations are a bit wacky.

  3. Since it looks like this is ramping up a bit, I'll ask some questions which I've asked myself and didn't really like the answer. Making maps is already a long process. Adding more advanced tech on top of that like cube maps, pbr, realtime lighting adds an extra complexity to the process and requires more attention by the mapper. How can you make this easier? The main example I have in my head is how big is the area influenced by the cube map? Like SomaZ already mentioned, you could add a radius to the misc_cubemap to restrict the area that is affected, but there's no easy way to are this area in Radiant. You can support dynamic lights but there's no good way to preview and adjust these without a long compilation time every single time you want to change it a bit. For PBR materials, its not so much of an issue because you generally need the right tools to make them in the first place.

     

    The only answer I can come up with that integrates well with the engine, is to build them into the engine. Make it possible for dynamic lights to be positioned when you're running around in the map. Draw where the cube maps are and show their radii and allow them to be moved around and resized. Maybe I'm wrong, but I think people will get frustrated with not having at least some realtime feedback.

     

    The alternative is to change radiant but that I think is a much bigger task.

    AshuraDX and Archangel35757 like this
  4. I've diverged from the ioq3 code base slightly so not all their changes are applicable. The PBR cvar could be ported but it's mainly a simplification of what was already available. Instead of having multiple cvars to enable pbr, they've been consolidated into one.

    minilogoguy18 and Smoo like this
  5. @@Xycaleth would you have any time to look at my crash please?

    I don't have a windows pc available for the foreseeable future so I won't be able to debug. I can say though you should never comment out error messages just to avoid them. They're there to report something bad happened and to avoid worse things from happening afterwards.

     

    For the COM_BeginParseSession problems, the error message is saying it was called too many times without Com_EndParseSession being called. Every time you call the begin session function, there needs to be an end session otherwise you'll get this error. In rend2 I think there's a few cases where the begin function is used, and might not have the matching end session to go with it.

     

    I don't think MP was so strict with this which is why It doesn't have the problem.

    Tempust85 likes this
  6. Usually this happens when your have a pk3 mod whose directory structure is too deep, or the folder names are too long. The full path of every file in the .pk3 needs to be less than 64 characters. If not, you'll get this error.

     

    There's nothing wrong with the error (it's not a memory leak), you'll just find some mods you have might not be usable or will be missing textures etc.

×
×
  • Create New...