rend2 support

[eezstreet]

I've started work on getting JK2:Enhanced working using rend2, based on SomaZ's work with DF2 mod (which made me realize how much code is actually shared between the two projects, interestingly enough). Currently so far I've got it merged in a rend2-sp branch.

 

Current status: it crashes upon startup with this error: https://pastebin.com/Gcpqphqq

[DT.]

About time lol.

I did the initial port of rend2 MP to SP, while SomaZ and uniqueone helped out with a few issues I had. SomaZ is now adding & tweaking things, so it's now his baby.

So I've changed all entities to be black when there's no lighting unlike vanilla, which has a minimum light. Other than that, I don't think I've made any other DF2-specific changes to the GL2 renderer. I pretty much leave renderer stuff to SomaZ now, so he has everything how he wants it without interference.

About that error. It could be an unsupported shader blend?

[SomaZ]

Fix for the mentioned problem:

https://github.com/SomaZ/OpenDF2/commit/1b5a553ab06460c50fc1bbd83d4650e469b8e434

[eezstreet]

*sparkle sparkle*
 

[SomaZ]

*sparkle sparkle*

Yey, vertex lighting! *_* (just kidding)

 

Ok, now I want you to ask if you got all the JO map files? PBR doesn't necessarily look good if you only use the new pbr materials. You also need new lighting. As I already told everyone in Discord I'm currently working on a new light system that's completely working on the GPU. This will result in very different light placements and the removal of all the fill lights that are extensively used in JO. I will also write support for the old shadow technique, which is used by the vanilla game (so one can choose between old shadows and lighting vs the new system, performance wise). The new system will completely ignore the pre-generated lightmaps and lightgrids and will only rely on the new light entities (and some diffuse environment probes that are automatically generated by the renderer to compute global illumination). We will keep the rend2 compatibility to the vanilla system, but will expand the system for much higher quality. This will require some additional love in mapping, besides the new materials.

 

I'm just writing this to make sure that you know what you've been up to. ^^

[DT.]

Isn't there a cvar to turn off lightmaps? That could be useful, and theres a compile only ents for q3map2. One could decompile the maps, add the new lighting and then compile only ents. Or, I read that JK enhanced can load ents from an external file.

[ensiform]

r_lightmap cvar is mostly a debugging of the lightmap not to toggle using it or not.

[eezstreet]

Yey, vertex lighting! *_* (just kidding)

 

Ok, now I want you to ask if you got all the JO map files? PBR doesn't necessarily look good if you only use the new pbr materials. You also need new lighting. As I already told everyone in Discord I'm currently working on a new light system that's completely working on the GPU. This will result in very different light placements and the removal of all the fill lights that are extensively used in JO. I will also write support for the old shadow technique, which is used by the vanilla game (so one can choose between old shadows and lighting vs the new system, performance wise). The new system will completely ignore the pre-generated lightmaps and lightgrids and will only rely on the new light entities (and some diffuse environment probes that are automatically generated by the renderer to compute global illumination). We will keep the rend2 compatibility to the vanilla system, but will expand the system for much higher quality. This will require some additional love in mapping, besides the new materials.

 

I'm just writing this to make sure that you know what you've been up to. ^^

I have *some* of the map files, but not all of them. My thought process is, if I can show what I can do with the .map files, I can talk people into giving me the rest.

 

Your system sounds complicated, but awesome. My only concern is, will it break the original lights in GL1?

[SomaZ]

It should be easier to use than the current lighting system. It won't break compatibility with GL1. It's simply some new entities to place on the map that are ignored by GL1.

[eezstreet]

It should be easier to use than the current lighting system. It won't break compatibility with GL1. It's simply some new entities to place on the map that are ignored by GL1.

Well, we'll also need some new textures as well.

[SomaZ]

Well, we'll also need some new textures as well.

Yea, sure. Without proper Materials everything will look strange.

[eezstreet]

Yea, sure. Without proper Materials everything will look strange.

Can you provide me with a version of q3map2 (and the entity name/properties/whatever) that works with your new lighting model, when it's ready?

[SomaZ]

Can you provide me with a version of q3map2 (and the entity name/properties/whatever) that works with your new lighting model, when it's ready?

Simple answer, no. Just because you wont need a new version of q3map2. ^^

[Archangel35757]

Should everyone be using @@UniqueOne's improved 64bit q3map2?

[eezstreet]

Simple answer, no. Just because you wont need a new version of q3map2. ^^

Ah ok, so it's just extra light entities?

If that's the case, in theory I won't need to have the map source if I can decompile and do an -onlyents bake run, like I've been doing already to optimize some of the waypointing the easy way.

 

Should everyone be using @@UniqueOne's improved 64bit q3map2?

wzmap has a lot of extra cruft that I don't think is really necessary.

[Archangel35757]

@@eezstreet- but it also has lots of improvements. Maybe there needs to be a cleaner, uncrufty version? @@UniqueOne

[eezstreet]

@@eezstreet- but it also has lots of improvements. Maybe there needs to be a cleaner, uncrufty version? @@UniqueOne

Like?

[SomaZ]

Ah ok, so it's just extra light entities?

If that's the case, in theory I won't need to have the map source if I can decompile and do an -onlyents bake run, like I've been doing already to optimize some of the waypointing the easy way.

Yea, only entities. Is there special code you use to read -onlyents bake runs or is it compiled to the bsp?

[eezstreet]

Yea, only entities. Is there special code you use to read -onlyents bake runs or is it compiled to the bsp?

Well, OpenJK supports an external .ent file, but I just bake it right into the .bsp. So basically yeah, it's compiled into the BSP.

 

What I do is pretty simple, and I'm surprised nobody has written a tutorial on this:

 

1. Decompile the original map using q3map2
2. Modify the entities from the .map using Radiant
3. Run q3map2 -onlyents
4. Bam, you've modified the map's entities.