Jump to content

rd-rend2 (old thread)


eezstreet

Recommended Posts

Glad to see you guys are still working pretty hard on this. And glad to see you now have proper Specular, Gloss, and Environment Cubes as well. I have known that you have had normals for a while, but seeing those editions are much more exciting to me.

 

I haven't been paying too much attention and mostly skimmed over things so I ask:

 

How much have you upgraded JKAs ability to use the power of newer computers? For example, baseJKA uses only roughly 15% of a GTX 660 FTW edition at maximum settings and as you know one CPU core. 

 

If yes to the previous, how much more room would we have for detail in meshes, brushes, and textures?

 

What version of Gloss/Roughness do you guys use? For example, UDK uses black for fully reflective, while Marmoset uses white. I am assuming you are using the White for fully reflective based off of the shader values posted.

 

What dynamic shadow model are you using? For example, I believe the most efficient, most recent, and highest quality variant for games is RTW (Rectilinear Texture Warping)

 

Have you guys increased JKAs ability to properly load textures & lightmaps (Higher resolutions, better efficiency like using texture aliases)?

 

What shader version/model have you guys been utilizing?

 

 

 

So far, you guys have been doing a good job from a visual standpoint. Maybe there is hope for me getting some of my newer stuff into JKA at some point. Like these: 

 

 

 

CZEw631.png

rhlFDa1.png

 

 

also incase this helps: http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf

DT. likes this
Link to comment

@@Xycaleth

 

misc_model & misc_model_static produce accurate visuals (just don't use modelscale with the misc_model_static or normal maps won't appear). Ghoul2 looks better than what it did with r_sunlightmode 1. Using r_forcesun 2, ghoul2 npcs/player models don't seem to receive light the same way as a misc_model_static does.

 

I would have though that all loaded models receive light the same way?

Link to comment

Glad to see you guys are still working pretty hard on this. And glad to see you now have proper Specular, Gloss, and Environment Cubes as well. I have known that you have had normals for a while, but seeing those editions are much more exciting to me.

 

I haven't been paying too much attention and mostly skimmed over things so I ask:

 

How much have you upgraded JKAs ability to use the power of newer computers? For example, baseJKA uses only roughly 15% of a GTX 660 FTW edition at maximum settings and as you know one CPU core. 

 

If yes to the previous, how much more room would we have for detail in meshes, brushes, and textures?

 

What version of Gloss/Roughness do you guys use? For example, UDK uses black for fully reflective, while Marmoset uses white. I am assuming you are using the White for fully reflective based off of the shader values posted.

 

What dynamic shadow model are you using? For example, I believe the most efficient, most recent, and highest quality variant for games is RTW (Rectilinear Texture Warping)

 

Have you guys increased JKAs ability to properly load textures & lightmaps (Higher resolutions, better efficiency like using texture aliases)?

 

What shader version/model have you guys been utilizing?

 

So far, you guys have been doing a good job from a visual standpoint. Maybe there is hope for me getting some of my newer stuff into JKA at some point. Like these: 

Hey Mace, it's good to see you're still lurking here :)

 

Firstly, we can't take credit for the current features in rend2. We're actually porting this across from the ioquake3 project which @@eezstreet started off, and now I'm continuing hopefully to completion. Once all the regular JKA stuff works I'm planning to rewrite a fair amount to take it to the next step.

 

JKA itself hasn't really been upgraded. It still only uses a single core - the aim of this is to up the renderer as far as we;re capable of doing. Having said that, I can tell you that the renderer is still very inefficient and currently it's doing too much CPU processing to feed the GPU fast enough (at least on my computer, with an i5 3750k and an AMD Radeon HD 6870). This is something that can be solved without utilising multiple cores though I believe... at some point I might look into using multiple cores but that would require a huge effort.

 

So my aim is to get somewhere near UDK-quality in terms of detail - using models will be preferred over regular brushes as the same models can be instanced/drawn in one go, rather than having to submit multiple draws. Textures, I'm not really sure how you can have more detail other than by making it bigger :P

 

I'm not sure what gloss/roughness algorithm we're using, I would have to delve into the code to find out.

 

For dynamic shadows, I believe rend2 uses cascaded shadow maps with regular PCF filtering (judging by the weird edge patterns I've seen). The shadows are kind of buggy so they need improvement. I don't think RTW is used by many (any?) games at the moment, so I'd prefer to go with something that's proven to work well.

 

Textures and lightmaps are pretty much the same. Rend2 attempts to pack lightmaps into a texture atlas, but nothing like that happens with regular textures - do games still do this? I plan to add support for .dds textures in the future to provide a fast path for texture loading. I'm still not decided as to what I want to do with lightmaps.

 

Shader models don't really apply to OpenGL but I can tell you that rend2 use features roughly equivalent to those found in DX10.

 

There's still a long way to go, and as you might have seen from the last few pages of the thread there's still a lot of teething issues. Hopefully all of this work will be worth it in the end though :)

 

Hopefully that answers all of your questions, @@MaceMadunusus!

Stoiss, Boothand and DT. like this
Link to comment

@@Xycaleth

 

misc_model & misc_model_static produce accurate visuals (just don't use modelscale with the misc_model_static or normal maps won't appear). Ghoul2 looks better than what it did with r_sunlightmode 1. Using r_forcesun 2, ghoul2 npcs/player models don't seem to receive light the same way as a misc_model_static does.

 

I would have though that all loaded models receive light the same way?

Which way looks better, misc_model or misc_model_static?

 

The reason they look different is because misc_models are actually baked into the map itself. When you create a misc_model, the geometry from the MD3 are taken from the file and inserted into the map file. They become part of the map geometry. With misc_model_static, they are essentially the same as regular game-entities. The advantage of this is you reduce the map filesize - the downside is it can potentially increase loading times as you now have to load the map and the model that you wanted to show.

Link to comment

misc_model & misc_model_static look the exact same, it's Ghoul2 that doesn't appear to receive light the same way as misc_model_static. When an MD3 has sun on it and I put a Ghoul2 in the same spot, the Ghoul2 is shaded in the areas where the sun is directly on it.

Link to comment

Which way looks better, misc_model or misc_model_static?

 

The reason they look different is because misc_models are actually baked into the map itself. When you create a misc_model, the geometry from the MD3 are taken from the file and inserted into the map file. They become part of the map geometry. With misc_model_static, they are essentially the same as regular game-entities. The advantage of this is you reduce the map filesize - the downside is it can potentially increase loading times as you now have to load the map and the model that you wanted to show.

And with misc_model ents you don't have to ship the md3 file with your pk3, with misc_model_static, you do.

Link to comment

Hey Mace, it's good to see you're still lurking here :)

 

Firstly, we can't take credit for the current features in rend2. We're actually porting this across from the ioquake3 project which @@eezstreet started off, and now I'm continuing hopefully to completion. Once all the regular JKA stuff works I'm planning to rewrite a fair amount to take it to the next step.

 

JKA itself hasn't really been upgraded. It still only uses a single core - the aim of this is to up the renderer as far as we;re capable of doing. Having said that, I can tell you that the renderer is still very inefficient and currently it's doing too much CPU processing to feed the GPU fast enough (at least on my computer, with an i5 3750k and an AMD Radeon HD 6870). This is something that can be solved without utilising multiple cores though I believe... at some point I might look into using multiple cores but that would require a huge effort.

 

So my aim is to get somewhere near UDK-quality in terms of detail - using models will be preferred over regular brushes as the same models can be instanced/drawn in one go, rather than having to submit multiple draws. Textures, I'm not really sure how you can have more detail other than by making it bigger :P

 

I'm not sure what gloss/roughness algorithm we're using, I would have to delve into the code to find out.

 

For dynamic shadows, I believe rend2 uses cascaded shadow maps with regular PCF filtering (judging by the weird edge patterns I've seen). The shadows are kind of buggy so they need improvement. I don't think RTW is used by many (any?) games at the moment, so I'd prefer to go with something that's proven to work well.

 

Textures and lightmaps are pretty much the same. Rend2 attempts to pack lightmaps into a texture atlas, but nothing like that happens with regular textures - do games still do this? I plan to add support for .dds textures in the future to provide a fast path for texture loading. I'm still not decided as to what I want to do with lightmaps.

 

Shader models don't really apply to OpenGL but I can tell you that rend2 use features roughly equivalent to those found in DX10.

 

There's still a long way to go, and as you might have seen from the last few pages of the thread there's still a lot of teething issues. Hopefully all of this work will be worth it in the end though :)

 

Hopefully that answers all of your questions, @@MaceMadunusus!

 

 

Hopefully you can optimize the usage of the renderer within that one core. At the very least, when you get to that point, it might be fine just separating the renderer from everything else so that all the game code, physics, network, etc can all sit on one core while the renderer can sit on another. That might be enough for JKA.

 

I don't think you are going to get to UDK's quality level without a ton of work. UDK is much more optimized than most engines out there. However, using meshes that draw in one go is certainly possible with the OpenGL version you are using which makes me happy :).

 

Cascaded shadow maps themselves are hugely inefficient in general. A few games do use RTW, not many at the moment because its still pretty new in the DX11 feature set and consoles didnt support them till the new ones came out.

 

A lot of games still do texture aliases. It is a pretty decent way to optimize texture rendering if you aren't using OpenGL 4+ (3.3 is likely what you are using) or DX11. An example of which was already mentioned, UDK :P

 

Should have likely said GLSL version there, but yeah you answered it.

 

Thanks @@Xycaleth!

Xycaleth and DT. like this
Link to comment
Guest KENNITHH

Got some questions via the dude who adds models to our "mod" in SOF2.

 

1) Is there a 500 verts limit and what is it?

2) Can you break the limit of 1000 verts?

3) Currently, the compilers used to get models into SOF2 (XSI exporter) mess up the smoothing. Is there any way to fix it?

 

And awesome information there guys. Feels good such pro's are working on this.

Link to comment

Not sure if the same limits apply to SoF2 as they do JK2/JA but in the JK series if you have a single mesh (not entire model) that is over 500 verts it will not cast dynamic shadows, this may be changed for the new render engine and was mainly the case in the vanilla renderer. The 1000 limit was something that would keep a model from loading at all, keep in mind these limits are per mesh object and every model can be made of 32 objects all together so the limit is much higher than you think, 32000 verts is the absolute maximum. Keep in mind the game engine does disconnect components along UV boundaries creating mode vertex's upon compile to GLM.

 

About the normals, sounds like a problem on your end, I personally am using Softimage and exporting to dotXSI 3.5 (3.0 can be used but there is no point) as it's my personal software of choice and the most fool proof way of getting a proper model file since other programs tend to either have trouble exporting a clean dotXSI 3.x file or have to use a file converter which tends to mess things up.

Link to comment

Got some questions via the dude who adds models to our "mod" in SOF2.

 

1) Is there a 500 verts limit and what is it?

2) Can you break the limit of 1000 verts?

3) Currently, the compilers used to get models into SOF2 (XSI exporter) mess up the smoothing. Is there any way to fix it?

 

And awesome information there guys. Feels good such pro's are working on this.

 

2) Can you break the limit of 1000 verts?

 

IF (and I say IF) this limit was removed from the game, you would only have this benefit from using Blender as it's a direct GLM exporter. Carcass has the same limit, but we don't have the source for it so it can't be removed. We would love to have carcass's source code for many reasons, this is just one of them.

 

 

 

3) Currently, the compilers used to get models into SOF2 (XSI exporter) mess up the smoothing. Is there any way to fix it?

 

Like minilogoguy18 explained about the UV boundaries. Can you please provide a comparison pic of what you have in your 3d package and what it looks like when converted? Also, what program(s) are you using to export to dotXSI?

Link to comment

I personally don't think the limits other than the dynamic shadows need to be removed since with normal mapping we have no need to increase polycount, if anything we can make lower polygon models than we used to and just use normal maps to increase detail.

 

Also, the dynamic shadows limit is something that is forced by the vanilla renderer, carcass just warns you of this but doesn't stop models from compiling. I'd imagine with rend2 this can be changed.

Archangel35757 likes this
Link to comment
Guest KENNITHH

Ok talked with the guy again and he told me to show you these pictures:

 

IApDNF6.jpg

fJntuod.jpg

 

He told me to say he uses 3ds Max and the plugins provided in SOF2SDK. Also, when he imports the GLM into Milkshape, he gets the one with no smoothing (black). The other one shows the smoothing after pressing CTRL+M (autosmooth).

 

He's also gonna give blender a shot.

Link to comment
Guest KENNITHH

Sorry for the delay guys but here's some more info:

 

He uses 3dsmax 5, Milkshape 1.8.5 and Modview

 

How he does it is:

Milkshape -> Export as 3DS -> Import 3DS in 3DSMAX -> Export as dotXSI -> Carcass -> dotXSI to GLM

 

He once tried to do it all in 3dsmax and it still got screwed up:

SMD -> dotXSI -> GLM

 

Here are the pics:

Modview:

91pM5UI.jpg

 

Ingame:

sNjpD7D.jpg

aE34Kvf.jpg

Link to comment

@@KENNITHH I'm not sure what I should be looking at in those 2 in-game screenshots? They look like they're different guns and what are the red circles showing?

 

Also, I've just realised you might need to do some extra work to get the Ghoul2 models working properly in SoF2 with rend2. JKA's version of Ghoul2 doesn't implement all the features that are required by SoF2.

Link to comment
Guest KENNITHH

Well both weapons show that it has some smoothing but in 3dsmax there aint no smoothing or atleast not that much at those places.. (mainly its smoothed at those light places)

 

I think RCF (from OpenSOF2MP) has already did the extra work but probably just needs the new renderer now.

 

But he's been inactive for a long period now.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...