Xycaleth

MD3s models can have more than 1000 verts, but the surfaces the model is made up from must have no more than 1000 verts each.

There are no textures, Neo. Fog is added by adding some extra 'foginess' on top of everything that is drawn. The further away something is, the more misty it looks.

Models are made up from a number of surfaces. Each surface has a limit of 1000 vertices, and each model has a limit of 32 surfaces.

Something about the lips doesn't look quite right but I'm not sure what. Too big maybe? Or maybe it's the lack of hair which makes the lips looks bigger?

@@BruceJohnJenner What compiler (+ version) are you using, do you know? I think you can type "cpp --version" in the terminal to find out.

OpenJK adds the ability for graphics renderers to be swapped in/out at run-time. rend2 is a heavily work-in-progress new renderer which brings some shiny modern rendering techniques like normal maps, real time lighting/shadows and stuff. Check out stuff here: http://jkhub.org/topic/2804-rd-rend2/page-3

It means the file isn't compatible with JKA at all. I don't know what the file contains.

Just an installer. When we do have a launcher, this would be the installer for the launcher instead. I'm not entirely sure how the uninstaller works at the moment (the entire installer and uninstaller and auto-generated by the build system), but I'll investigate. I think we'll keep thinks really simple for now though, so probably it will only remove files that the installer created but I need to double check.

I'll investigate the possibility. I think this is the cleanest way to ensure assets are in the right place but some people might not like having two copies of JKA. I'm not sure how stable it is at this point. I don't think it's been used as much as JKA SP and I imagine there's a number of problems with save files etc. I think it's better if we defer it to a later release where it will be more polished.

The core files are DLLs only. You can choose to install only the client files (OpenJK.exe and the renderer) or only the server file (openjkded.exe). I probably need to rethink the grouping because you can end up installing only the DLLs and not have a working game.

I'm pretty sure discussions about ported content have come up before, with the consensus that: 1. Yes there is ported content on jkhub but the staff aren't going to go through every file to see if it's ported. If people request it to be taken down, then it will be checked out. 2. New submissions will be checked for ported content (and rejected if it does contain such content?) 3. Games come with end user license agreements saying that you should not do this, shouldn't do that, you can do this etc. Usually there's a clause saying that you must not distribute the contents of the game (more like, must not copy the game whether by electronic transmission or otherwise). So you could say that the person who made the model available is at fault. But then there's also the issue of creating derivative works from copyrighted content. Yes modding communities will copy off of each other, taking bits from here and there, but I think people expect it to happen. It's the culture of modding you could say or an unspoken law, and that's why people then explicitly request that people don't copy/use their content. Copying off companies is a bit different though. They usually explicitly deny assets from being copied, and even if they didn't, it's illegal to copy creative works unless permission is explicitly given (to do with derivative works etc) or if you fall under the fair use category. I doubt copying a model wholesale is fair use though personal use might come under fair use too? I'm not sure. All that said, jkhub are just trying to cover their backs. Putting yourself in the staff of jkhub, would you rather be safe or take the risk of getting shut down and losing this great community? I'm writing this on a phone and it's taken forever. So apologies if none of it makes sense

I was going to create a topic to explain how work on the first release is going, and how we're achieveing it, but this will do for now. I'll expand on this in a few days Ignore the version number

Since when did teeth differ between genders? o_O

Post them all bro'.

Not that I can think of. The flag is meant to tell the renderer that the lighting origin was setup, and can be used for lighting. However, the lighting origin setup was commented out (above the line that you edited) so it was just lighting the model from a random location. I had Cerez test the fix for me because I couldn't reproduce the problem. I've added the change to the OpenJK source code now, so yes, it will be fixed in future versions of OpenJK!

GLA files only store animations, nothing else. Any other information related to how animations are used and when are either stored in a separate file or hard coded in the game's source code By the sounds of it, the game you for this GLA file from just happens to use the same file extension. They're not actually the same file format as the one used by jka

Hi! That doesn't look like a .GLA file to me either. Where did you get it from?

So the problem with my Kyle model was because of a bad custom shader I had Ignore that!

I don't get anything on Luke, only Kyle:

Are you sure it's a shadow and not the model itself? You have a different Luke model from the base JKA one and the 'shadow' on Luke's face in your screenshot doesn't match his hair at all. EDIT: Nevermind, I see the problem on Kyle now.

I think I saw this issue in jedicouncilgcx, but I didn't know at the time that it was a video shader. I recall it just showing a grey texture instead of the video texture but I didn't have time to look at it at the time.

En français: https://translate.google.com/translate?hl=en&sl=auto&tl=fr&u=http%3A%2F%2Fjkhub.org%2Ftopic%2F5427-free-web-hosting-shutdown%2F There might be a few mistakes, but it should be a pretty good translation

It's possible to do this, but the solution isn't obvious - you draw them in reverse order. Let's call your 'background texture', texture A, and your scrolling texture, texture B. Stage 1: Draw texture B as usual, with default blendFunc and scrolly fun. Stage 2: Draw texture A, with blendFunc GL_ONE_MINUS_SRC_ALPHA GL_SRC_ALPHA Your scrolling texture get's drawn first, and is the destination texture for stage 2. In stage 2, you multiply texture A's RGB values by (1 - alpha of texture A). So where the alpha is white (1), you get texture A RGB * 0, so none of texture A is used, but then you add on texture B RGB * 1 (which is the full colour of texture B ). When the alpha is black (0), the opposite happens. You get the full colour of A, and none of B. It just takes experience and some creativity to figure out what to do with your blendFuncs but if you understand the basic concepts of how the blending works, then you should get there eventually

If the Source SDK code is anything to go by, it's anything but clean

blendFunc is fairly simple to understand. All colours can be represented using 3 numbers, Red, Green, Blue, with a 4th number for transparency (the alpha) - in Photoshop or GIMP, you can use the colour picker to show you these numbers (or components) of the colour. These values are in the range 0 - 255. In graphics, you "normalize" these values, so they become 0.0 - 1.0. blendFunc is a way to tell the graphics card how you want two colours to be blended, where the first colour is the source, and the second colour is the destination (i.e. what's already been drawn). Blending then happens like so... sourceColor * srcBlendFunc + destinationColor * dstBlendFuncSo for example, you might write "blendFunc GL_ONE GL_ZERO". GL_ONE is your srcBlendFunc (source blend function), and GL_ZERO is your dstBlendFunc (destination blend function). GL_ONE GL_ZERO also happens to be the default blendFunc. The maths then works out like this: final color = source color * 1 + destination color * 0You can simplify this because 0 * x = 0. final color = source colorLet's take another example... blending based on alpha transparency is pretty common. This is "blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA". The final colour is then calculated: final color = source color * source color's alpha + destination color * (1 - source color's alpha)Thinking about this intuitively, if the source colour's alpha = 1, then none of the destination colour is shown, and you effectively get the same as GL_ONE GL_ZERO. If source colour's alpha = 0, then you're fully transparent, and you see the destination colour in full as you would expect. Fractional values in the source colour's alpha will make the source colour more or less transparent. All of the blendFunc names are pretty named very well so you can work out what they do by plugging them into the first formula I gave. The last important piece of information is that the final colour that's calculated is the destination colour for the next shader stage. Hopefully that's clear enough. I'm writing this at work so my post isn't as detailed as I'd like it to be, but I think it's enough to go on. Let me know if you need any more explanation and I'll try my best EDIT: Didn't read your post properly, so I missed a point. The colour buffer is the "texture" that gets drawn to your screen. However, you won't see the results of your calculations until it gets "presented" to the display. This way, you can overwrite/blend/clear existing colour pixels without you seeing any of the intermediate results. EDIT2: I've been wanting to write a simple WebGL application that lets you play with blend functions in a web browser, but have never gotten around to doing it. It would be great if someone could do this as seeing how the blend functions works in action can make understanding a lot easier.