Xycaleth

Yeah, parallax maps should be supported. I don't know to what extent though. I'm still learning the ins and outs of rend2 as I go along fixing things.

That thread is based on baking cloth physics into the animation. There's no cloth physics involved on the game engine side of things.

Unless someone wants to contribute their time to add it, then it doesn't look likely at the moment.

The renderer is now much improved.

The auto-generated normal maps are also not that great - think of the normal map generator in Photoshop - it's something along those lines.

 

Regarding normal maps from q3map2, rend2 does support something it calls 'deluxe maps'. These are used in Half Life 2, and essentially create normal maps for the lightmaps, but still need to be fixed. I want to look at eventually replacing this though with something a bit lighter weight though as deluxe maps take up a lot of memory.

Keep in mind that the majority of our work here is just porting the rend2 renderer from ioq3 to JKA. There's just a lot of small differences between the regular Q3 engine and the JKA engine which means rend2 doesn't quite work properly! So we can't take all the credit for what you see Our work so far has been bridging these small differences so that it does work.

Excuse my ignorance, but uhm what is rend2?

Pretty much as soon as the full JKA source code was made available, a few of us started working on a more polished version of the jasp/jamp files. This also led to us starting a port of the rend2 renderer used in ioq3 - in short it's a drop-in replacement for the standard JKA renderer which provides a few techniques you'd expect of a modern graphics engine like normal maps, HDR lighting, depth of field etc. We have a WIP thread over in the OpenJK forum: http://jkhub.org/topic/2804-rd-rend2/?p=40366

I started making one a few years ago but gave up on it after a while. It would be good if someone does make something like this though.

If an assertion has triggered then it's a really bad idea to ignore it, especially if it's coming from the C runtime. You probably want to go up the call stack until you reach OpenJK and see what it's calling, and with what input.

Reading through some of the jkhub posts, one post in particular got me thinking. The post was along the lines of "too bad all the people who can make decent mods are too busy to make anything". This is true in a way. A lot of the experienced modders are now midway through college or are now working professionals. Which brings up another point: all these modders were probably the same age as the majority of the now-non-modders when they first started to learn about modding.

 

What's stopping the non-modders from learning to mod, especially when there's definitely more tutorials available now compared to a few years ago? Make of this what you will

Maybe @@Szico VII can tell you

Dem shadows.

I would go for an AMD card. Their OpenGL driver has gotten a lot better over the past few years, and the Radeon 280x seems pretty good. Add to the fact that AMD's Mantle graphics API is being introduced soon, which, if their numbers are marketing are anywhere near real numbers, will be an advantage over Nvidia (though only for games that support Mantle).

Small update on this. I've been slaving away at this, to make it working better. Here's a few screenshots of what rend2 is capable of:

 

Notice the variation in shadows across the face of the lit rock surface. Rend2 can naively auto-generate normal maps using the textures you give it.

 

Dynamic shadows that affect all things in the map. It's a bit of an FPS as you can see, but this can eventually be optimised. (Ignore the Wampa with huge burn marks - GLM model rendering is still WIP )

I remember you @@Almightygir

 

1. has anybody attempted this already? and if so, what success has there been?

Like @@DT85 said, OpenJK has separated the renderer code from the main game program so you can swap out the renderer for your own renderer. I'm currently in the progress of porting rend2 to OpenJK. Rend2 (it's one of the renderers used by ioq3) uses GLSL shaders behind the scenes to allow for some more fancy graphics, but the 'materials' are still described using a Q3-shader based system to make it simpler for artists to create them. There is some scope to add new GLSL shaders but it would require some knowledge of the renderer code as well to add them in and get them to be used.

You've run out of memory. You can try adding -lomem but this would drastically increase compilation time. Failing that I don't think there's a lot you can do.

 

On a related note, Windows XP won't be able to use all 8GB of your memory. It will only use about 3GB because it's a 32 bit operating system.

Nevermind my original post... I can't read what happens if you don't link the NPC to the waypoint?

 

Original post:

Is this for JKA or JK2? Rich's NPC tutorial might only work correctly for JK2.

Bounding box shouldn't be a problem. The cloth will just go straight through any walls or crate objects - there won't be any additional collision checking for it. As DT said, the game only uses a standard bounding box for collision detection against the map.

OpenJK should be playable on Mavericks now.

Awesome. I thought the Stormtrooper looked a bit weird in-game... lol

@@Asgarath83 Do you still have the FBX files that you converted? Or do you know if your friend still has them? They would be very useful to some people here

Okay that sounds reasonable

Probably, but if a different scale is used from that specified in the GLA then the animations won't look right. When I get around to writing the GLA exporter I'll take the scale from the FBX file and write it into the GLA file.

Didn't you say that noesis renders the FBX correctly though? If that's the case then I'm probably doing something wrong.

 

Model is already be scaled by the scaling factor specified in the GLA file For the humanoid GLA this is 0.64.

Subtle bugs are subtle I have a feeling this is somewhat related to the hand guard being in completely the wrong place, and will take a bit longer to figure out... why most of the other surfaces are in the correct place and not the guard is still a mystery to me.

 

Thinking about it more, it might be another Ravenism (new word of the day?) where there's an odd quirk to exporting to GLM and they've just hacked around the problem in carcass rather than fixing it :/