[JAEnhanced] Enhanced Development Platform (EDP)

[eezstreet]

I mean that JK2:Enhanced and JA:Enhanced are on the same repository, not in two separate repositories. Sorry if I was unclear about that.

[MoJo JoJo]

IMO, the TrueView 1.0 looks the best (looks more realistic).

[z3filus]

Yea that 1.0 looks really nice, the only problem (for me at least) is that the arm+animations, or lack of proper animations, makes it look like you have a prosthetic arm. TrueView requires new, realistic animations, for starters, make the hand look like it actually holds the gun in a tight grip, lol.  But that's just me being nitpicky. This is really nice ^^

[MoJo JoJo]

Yea that 1.0 looks really nice, the only problem (for me at least) is that the arm+animations, or lack of proper animations, makes it look like you have a prosthetic arm. TrueView requires new, realistic animations, for starters, make the hand look like it actually holds the gun in a tight grip, lol.  But that's just me being nitpicky. This is really nice ^^

Lel yeah, a prosthetic arm was exactly what I was thinking of when I saw it. Doesn't look quite like that when your using a weapon that's held by two hands- certain ones like the repeater, rocket launcher, flechette etc.

[Smoo]

That's awesome

[eezstreet]

Lel yeah, a prosthetic arm was exactly what I was thinking of when I saw it. Doesn't look quite like that when your using a weapon that's held by two hands- certain ones like the repeater, rocket launcher, flechette etc.

The effect can probably be made to look better with a lower FOV.

[Archangel35757]

The effect can probably be made to look better with a lower FOV.

...or better/higher quality view models and proper animations

[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. ^^

[Tempust85]

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.

[eezstreet]

Old news, but needs to be documented: EDP has support for SFX Sabers. SFX Sabers are dramatically higher quality than the base game lightsaber rendering and can be toggled with the cg_sfxSabers cvar.

 

Available for both JK2 and JKA.

 

Original Lightsabers:

 

 

 

 

 

SFX Sabers:

 

 

 

 

 

Video comparison:

 

Perhaps this answers your question, @@DT85 ?