Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Show skybox cubemap. #96

Open
stoofphen opened this issue Mar 1, 2022 · 7 comments
Open

Feature Request: Show skybox cubemap. #96

stoofphen opened this issue Mar 1, 2022 · 7 comments

Comments

@stoofphen
Copy link

stoofphen commented Mar 1, 2022

Basically the feature in JACKHAMMER / CoD2Radiant / CoD4Radiant, which reads the sky shaders in the editor and projects them as a cubemap as they would be seen in-game. It's kind of a minor cosmetic, but I feel it adds nicely to the editor and mapping experience of being able to visualise the selected skybox. If you are to investigate this (would be most appreciative!) bonus points if you can also somehow get it to render the props_skyportal / misc_skyportal entities as well! (maybe even the q3map2 _skybox entity which visualises 'scaled' geometry).

As a side note of appreciation; Thank you for developing such a robust Radiant! I've been using basically all variations of Radiant under the sun since around 2007, this by far is the most cleanest and reliable one I have used, and most versatile as well. I honestly cannot use another editor without feeling that same sense of competency and comfort as I do with Radiant.

(Examples below)

image
image

@Garux
Copy link
Owner

Garux commented Mar 3, 2022

Thank you. Atm I'm in creation of huge skies pack for mapping and got feeling that this would be worthy, at least for previewing boxes.
How drawing sky brushes is organized in these examples? If rendering box in a classic way, rendering brushes is questionable.

@stoofphen
Copy link
Author

stoofphen commented Mar 4, 2022

Indeed, would definitely assist with checking the cubemap quickly in editor when creating them, rather than having to compile the map and running the game to see it..

In terms of the technical details of how this may be handled - I am not really an expert on this. I have provided more context on usage below, if that is of any use.

For CoD2 radiant, it renders the cubemap as part of the brush you assign the texture to. Interestingly, allows for multiple different skies to be rendered (with obviously one taking precedence over the others if viewed overlapped).

CoD2.Radiant.Skybox.Eg.mp4

.

Whereas for J.A.C.K. - in the context of Gold Source, you input the cl_skyname variable for the env cubemap name in GFX (corresponding _ft, _lf, _rt etc images) and it renders over the SKY texture, similar to CoD2 Radiant's.
image

Do you think such a thing would be easy or difficult to implement in terms of having a brush with the 'surfaceparm sky' render the corresponding 'skyParms' cubemap as part of the actual brush geometry itself?

Otherwise, maybe a fallback would be to render a cubemap as part of the 3D camera background, associated with path to the cubemap images?

Food for thought.

@Garux
Copy link
Owner

Garux commented Mar 4, 2022

Rendering part of cubemap looks optimal in terms of features, idk how messy is implementing this, at least is not super trivial.

@ensiform
Copy link

ensiform commented Mar 5, 2022

How would it work when differentiating between shader usage for Quake 3 engines vs no shader for legacy engines? Not to mention mtr for tech4 if supported.

@Garux
Copy link
Owner

Garux commented Mar 5, 2022

It wont, would need to render sky box, as in engine (speaking of case, when sky is defined by some key, right?).
Pros of rendering part of cubemap at a polygon for shader way:

  • visible, selectable, manipulatable brushes
  • multiple skies
  • no need to track used sky shader

@Garux
Copy link
Owner

Garux commented Jul 20, 2022

Added Q3 skyboxes rendering like in CoD2 d3e48d8.
Rendering cloud layers boils down to reimplementation of Q3 shaders parser and its renderer (done in JACK).
Getting _skybox geometry requires bsp building (thing not to do in runtime).
Most doable of these look entity defined skyboxes, require special observer for them and special rendering code.

Garux referenced this issue Jul 20, 2022
logic: load 6 skybox textures when shader gets used by scene, don't unload dynamically, just on 'flush'
texture browser only uses normal preview image and doesn't trigger potentially heavy box loading
also fix R_ResampleTexture for [2+x upscaling
@stoofphen
Copy link
Author

stoofphen commented May 2, 2023

Been a while since this post, however just wanted to say a big thank-you for implementing this! Really makes the adjustment of the the _sun light angle to match the skybox much easier too!

Understanding _skybox is part of the bsp build, however I am aware that the Star Trek Elite Force II UberRadiant (part of STEF2 UberTools GDK) has capability to render the skyportal geometry, which I think you could offset its movement based on the 3D camera view, relative to the origin of the world (0,0,0) which is scaled by the skyportal 'scale' factor.

In UberRadiant, set up is basically create a script_skyorigin entity (much akin to the misc_skyportal / props_skyportal) and 'F10' enables the Skyportal view as the 3D camera background. This is refreshed to take whatever the visible state of the map is, so you can see I've hidden some walls which make it hidden in the 3D camera background accordingly.

image

image

If you are interested, you can test for yourself.
https://www.moddb.com/games/star-trek-elite-force-ii/downloads/stef2-bertools-game-devolopment-kit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants