Jump to content

rend2 questions


eezstreet

Recommended Posts

So I was wanting to poke some people's brains (Mostly @@Xycaleth's) to see what will be and won't be supported under rend2. Will we expect to see deluxe mapping? (what is deluxe mapping, even?)

 

I see there's some stuff for cubemaps, not sure how you're going to proceed with it.

 

Will there be changes/additions in BSP lumps?

 

What about dynamic lights? Are these going to project shadows? Will shaders be able to produce dynamic lights? (blinking computer screens come to mind)

 

I ask because I was going to hex-edit the BSPs in JK2 in order to give them some better visuals in rend2, as well as alter the shaders. I wanted to preview the changes on MP first, until we figure out how to proceed with rend2 on SP (read: I add in the preprocessor stuff required)

 

I'm thinking about using the same code for rend2 on SP, just a preprocessor command to specify it as being SP instead of MP

Link to comment

@@eezstreet I hope to support deluxe mapping but it will need support from q3map2 as well (I think?). Q3map2 does generate deluxe maps but I'm jot sure if it will generate them for JKA maps. It might be something for later rather than sooner. To answer what it is, it's essentially a normal map for the lightmap so that it doesn't seem so static when lights shine across the map surfaces.

 

I'm not exactly sure what you mean by cube maps in this context, and as I'm on the bus right now I'll reply with more information later on today.

 

There won't be any changes to the BSP format for conpatibility sake.

 

I'm hoping dynamic lights will be able to project shadows, but only for up to say 4 or 8 lights. I don't see why shaders won't be able to emit light... Will need to look into this as well :P

Link to comment

@@eezstreet I hope to support deluxe mapping but it will need support from q3map2 as well (I think?). Q3map2 does generate deluxe maps but I'm jot sure if it will generate them for JKA maps. It might be something for later rather than sooner. To answer what it is, it's essentially a normal map for the lightmap so that it doesn't seem so static when lights shine across the map surfaces.

 

I'm not exactly sure what you mean by cube maps in this context, and as I'm on the bus right now I'll reply with more information later on today.

 

There won't be any changes to the BSP format for conpatibility sake.

 

I'm hoping dynamic lights will be able to project shadows, but only for up to say 4 or 8 lights. I don't see why shaders won't be able to emit light... Will need to look into this as well :P

Are the deluxe maps part of the BSP? Or a separate file?

 

By cubemaps, I mean environment mapping. Course, if that's supported without anything extra, I'll probably be happy as well. I see there's stuff in rend2 for "cube mapping" but I'm not sure what that is. My guess is environment mapping?

 

By BSP format, do you mean RBSP or IBSP? I suppose you could add support for IBSPs as well, I don't see why you couldn't per se. I'd be behind supporting both formats as IBSP would provide many benefits in terms of graphics capability.

 

Why such a low cap on the number of dynamic lights? And by shaders emitting light, I mean dynamic lights. So for instance, computer monitors on kejim_post and various cairn levels would emit blue light that flickers slightly on maybe one of the terminals. 

 

Also, what about the limits on vertexes? Is there any difference in the number of vertexes per object that's supported? Currently you can't go any higher than 1024 per object, which is a significant limit. I know you mentioned multithreading the renderer. Are there any significant bottlenecks in rend2 that limit performance with high numbers of vertexes? I believe you mentioned that ghoul2 transforms are a significant impact. Have these been alleviated at all with the prevalence of Ghoul2 being handled via VBOs (and therefore on the GPU)?

 

Sorry if these questions are too much, I just want to see how much performance/graphical power I can squeeze out of rend2.

 

EDIT: one other thing. You mentioned that graphics cards for years have been able to do non-power-of-two textures. Are there any significant consequences for disabling the non-PoT limit, other than perhaps load times? This could be quite excellent for things without mipmaps, as they tend to get stretched on screen in ugly ways.

Link to comment

Are the deluxe maps part of the BSP? Or a separate file?

Yep, part of the BSP file. But they're stored in such a way that remains compatible (I believe) with the vanilla renderer.

 

By cubemaps, I mean environment mapping. Course, if that's supported without anything extra, I'll probably be happy as well. I see there's stuff in rend2 for "cube mapping" but I'm not sure what that is. My guess is environment mapping?

Ah yeah I remember now. Yeah, rend2 supports environment mapping so you can place misc_cubemap entities around the map, which act as the environment probes, i.e. the locations from which environment maps should be generated. I'm not sure if these are dynamic or not though. I imagine they are.

 

By BSP format, do you mean RBSP or IBSP? I suppose you could add support for IBSPs as well, I don't see why you couldn't per se. I'd be behind supporting both formats as IBSP would provide many benefits in terms of graphics capability.

RBSP format. As far as the plain rend2 renderer goes, I don't plan on adding IBSP support because it's extra work that doesn't really give many benefits.

 

Why such a low cap on the number of dynamic lights? And by shaders emitting light, I mean dynamic lights. So for instance, computer monitors on kejim_post and various cairn levels would emit blue light that flickers slightly on maybe one of the terminals.

I should have been more clear. That's 4 - 8 dynamic lights which can cast dynamic shadows. I don't think having more dynamic lights than that, which don't cast shadows, should be a problem...

 

Also, what about the limits on vertexes? Is there any difference in the number of vertexes per object that's supported? Currently you can't go any higher than 1024 per object, which is a significant limit. I know you mentioned multithreading the renderer. Are there any significant bottlenecks in rend2 that limit performance with high numbers of vertexes? I believe you mentioned that ghoul2 transforms are a significant impact. Have these been alleviated at all with the prevalence of Ghoul2 being handled via VBOs (and therefore on the GPU)?

Vertex limits are remaining the same for now. I've moved the Ghoul2 rendering completely to VBOs in rend2 but there's not really much performance gains from it at the moment - FPS is either the same or worse in most cases. There's a lot of work to be done to get rend2 to the frame rate I want to see and I'm not sure what parts are slowing the renderer down at the moment.

 

You mentioned that graphics cards for years have been able to do non-power-of-two textures. Are there any significant consequences for disabling the non-PoT limit, other than perhaps load times? This could be quite excellent for things without mipmaps, as they tend to get stretched on screen in ugly ways.

I don't think there will be any noticeable differences.
Link to comment

I think it should be okay... are you planning to add the #if blocks to the MP rend2, or are you making a copy in the SP folder?

I'll be adding the #ifdef/#if defined blocks to MP rend2, but that project (SP rend2, which has _SP defined) will have the includes directory set to /code/, so that it includes the SP qcommon files

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...