blender
/
blender
133
398
Fork 579
Code Issues 6.3k Pull Requests 745 Projects 19 Wiki Activity

EEVEE-Next: Add operator to convert a world volume to mesh #119734

Open
Jeroen Bakker wants to merge 3 commits from Jeroen-Bakker/blender:eevee-next/convert-world-volume into main
pull from: Jeroen-Bakker/blender:eevee-next/convert-world-volume
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 17 Commits 3 Files Changed 3 +147
Jeroen Bakker commented 2024-03-21 12:14:32 +01:00
Member
Copy Link

EEVEE-Next world volume are infinite like Cycles. EEVEE-Classic world volumes
ended at the clip_end of the camera/viewport. This can lead to confusion as
it would render different then expected.

This PR adds an operator to convert a world volume to a mesh volume.
The mesh volume is bound to the active scene camera.

Why an operator?

As this alters the content of the scene we want the artist to be in control of
the conversion.

TODO

  • Test with more scenes and different setups.
EEVEE-Next world volume are infinite like Cycles. EEVEE-Classic world volumes ended at the clip_end of the camera/viewport. This can lead to confusion as it would render different then expected. This PR adds an operator to convert a world volume to a mesh volume. The mesh volume is bound to the active scene camera. **Why an operator?** As this alters the content of the scene we want the artist to be in control of the conversion. **TODO** - Test with more scenes and different setups.
eevee-next-convert-world-volume.mp4
4.2 MiB
❤️ 2 🎉 2
Jeroen Bakker added this to the 4.2 LTS milestone 2024-03-21 12:14:32 +01:00
Jeroen Bakker added the
Module
EEVEE & Viewport
 label 2024-03-21 12:14:32 +01:00
Jeroen Bakker self-assigned this 2024-03-21 12:14:32 +01:00
Jeroen Bakker added 1 commit 2024-03-21 12:14:41 +01:00
3b6fabab34 EEVEE-Next: Add operator to convert a world volume to mesh 
EEVEE-Next world volume are infinite like Cycles. EEVEE-Classic world volumes
ended at the clip_end of the camera/viewport. This can lead to confusion as
it would render different then expected.

This PR adds an operator to convert a world volume to a mesh volume.
The mesh volume is bound to the active scene camera.

**Why an operator?**

As this alters the content of the scene we want the artist to be in control of
the conversion.

**TODO**

Add the operator to the Outliner and as an object operator in the 3d viewport.

matches Cycles more closer.
Scenes that
are created with EEVEE will
Jeroen Bakker added this to the EEVEE & Viewport project 2024-03-21 12:14:47 +01:00
Jeroen Bakker added 1 commit 2024-03-21 12:38:19 +01:00
Jeroen Bakker requested review from Pablo Vazquez 2024-03-21 12:39:25 +01:00
Jeroen Bakker requested review from Clément Foucault 2024-03-21 12:39:42 +01:00
Jeroen Bakker commented 2024-03-21 12:40:47 +01:00
Author
Member
Copy Link

I already send this one in for review to discuss the best location where to add the operator in the menus.

  • Object -> Convert isn't ideal as it doesn't relate to the current selected object.
I already send this one in for review to discuss the best location where to add the operator in the menus. - Object -> Convert isn't ideal as it doesn't relate to the current selected object.
Jeroen Bakker added 1 commit 2024-03-21 12:43:38 +01:00
Donovane commented 2024-03-22 09:50:17 +01:00
First-time contributor
Copy Link

This thing permit to create the beginning of probe volume based on the world (Sparse grid LIKE adaptive probe volume) (for using probe with surfels instead raytracing or, with raytracing) ?

This thing permit to create the beginning of probe volume based on the world (Sparse grid LIKE adaptive probe volume) (for using probe with surfels instead raytracing or, with raytracing) ?
Clément Foucault added the
Interest
EEVEE
 label 2024-04-15 10:35:32 +02:00
Clément Foucault requested changes 2024-04-22 19:43:06 +02:00
Clément Foucault left a comment
Member
Copy Link

So we had a discussion with Pablo about this and we both think it is better to go with the versioning approach. The reason is that users should not have to make any input to see their file work in newer version.

So we listed made a list of things to do in order to make it the cleanest as possible.

- For every scene
  - Skip scene if it uses Cycles as active renderer and if the world doesn't contain a volume nodetree attached to a EEVEE only output.
  - If scene uses a world already processed, just link the same collection
  - Otherwise:
    - Create a collection
      - Make collection a child of scene collection
      - Make sure it is at the bottom of the outliner
    - Add icosphere with low subdivision level
      - Scale it to 1e10
      - Add it to the collection
      - Remove all attributes except position (don't want extra data)
      - Disable workbench shadow
    - Add new material
      - Assign material to the icosphere
      - Copy branch of the world volume tree
      - If the world volume was linked to a EEVEE only output
        - Make the volume output node an EEVEE only output node
        - Add a Cycles only output node and add a transparent shader node for the surface output to avoid making it affect cycles
    - Rename the Collection, the Object, the Mesh Data and the Material as {world.id.name} + "_volume"
- If any modification was done emit a message about modified scene. (Report info message) "World volume has been converted into an object"
So we had a discussion with Pablo about this and we both think it is better to go with the versioning approach. The reason is that users should not have to make any input to see their file work in newer version. So we listed made a list of things to do in order to make it the cleanest as possible. ``` - For every scene - Skip scene if it uses Cycles as active renderer and if the world doesn't contain a volume nodetree attached to a EEVEE only output. - If scene uses a world already processed, just link the same collection - Otherwise: - Create a collection - Make collection a child of scene collection - Make sure it is at the bottom of the outliner - Add icosphere with low subdivision level - Scale it to 1e10 - Add it to the collection - Remove all attributes except position (don't want extra data) - Disable workbench shadow - Add new material - Assign material to the icosphere - Copy branch of the world volume tree - If the world volume was linked to a EEVEE only output - Make the volume output node an EEVEE only output node - Add a Cycles only output node and add a transparent shader node for the surface output to avoid making it affect cycles - Rename the Collection, the Object, the Mesh Data and the Material as {world.id.name} + "_volume" - If any modification was done emit a message about modified scene. (Report info message) "World volume has been converted into an object" ```
Jeroen Bakker commented 2024-04-28 08:28:57 +02:00
Author
Member
Copy Link

@fclem @pablovazquez I have doubts about this solution. As this is different than previously asked to do and the design doesn't cover all scenarios.

User perspective:

  • Users have different expectation when using linked scenes or worlds. Collections can be easily added to incorrect blend files and might also be created multiple times (in different blend files) changing the final pixel result. The main reason why we never alter user data during versioning.
  • Dragging and dropping of world assets can lead to adding collections and objects that will not be removed when draggin and dropping the next world asset. Resulting into similar issues.
  • The data management of this design isn't defined and will be unclear to users what they need to do when something is incorrect. What needs to be done is also not clear. A user can detect that something went wrong during conversion, but doesn't have a clue where it originates from. One reason why user data should only be changed via an operator.

Developer perspective:

  • Development needs to be done in C/CPP which adds a different level of complexity, quality and maintainability.
  • As this is part of the versioning, we now we need to support it for-ever. Although the code will typically be used in a short stretch of time.
  • I doubt that we have all the different test cases in place to ensure that this mechanism will work for all cases. Creating it difficult to sign off for completion.

So basically the proposal isn't complete as it only covers the basics. I expect the total lead time can go easily into 3-4 weeks, development including support. We might even come into a situation where we don't want this as the expectation for users are different, but they need to do additional work.

All in all I doubt this proposal will fit the schedule or works for the users as intended.

@fclem @pablovazquez I have doubts about this solution. As this is different than previously asked to do and the design doesn't cover all scenarios. **User perspective**: - Users have different expectation when using linked scenes or worlds. Collections can be easily added to incorrect blend files and might also be created multiple times (in different blend files) changing the final pixel result. The main reason why we never alter user data during versioning. - Dragging and dropping of world assets can lead to adding collections and objects that will not be removed when draggin and dropping the next world asset. Resulting into similar issues. - The data management of this design isn't defined and will be unclear to users what they need to do when something is incorrect. What needs to be done is also not clear. A user can detect that something went wrong during conversion, but doesn't have a clue where it originates from. One reason why user data should only be changed via an operator. **Developer perspective**: - Development needs to be done in C/CPP which adds a different level of complexity, quality and maintainability. - As this is part of the versioning, we now we need to support it for-ever. Although the code will typically be used in a short stretch of time. - I doubt that we have all the different test cases in place to ensure that this mechanism will work for all cases. Creating it difficult to sign off for completion. So basically the proposal isn't complete as it only covers the basics. I expect the total lead time can go easily into 3-4 weeks, development including support. We might even come into a situation where we don't want this as the expectation for users are different, but they need to do additional work. All in all I doubt this proposal will fit the schedule or works for the users as intended.
Clément Foucault commented 2024-04-28 10:11:10 +02:00
Member
Copy Link

Development needs to be done in C/CPP which adds a different level of complexity, quality and maintainability.

I share this concern. But even if the list of things to do is long, it isn't very hard to do for the most part. The only tricky part is dealing with nodetrees.

Users have different expectation when using linked scenes or worlds. Collections can be easily added to incorrect blend files and might also be created multiple times (in different blend files) changing the final pixel result. The main reason why we never alter user data during versioning.

We should only convert worlds local to this file, which is safer for data management. This mean users will have to fix file in inclusion order. Which I think is sound.

If a user opens an asset file that has a world volume, saves it, and then load a set file that link the world data block, in that instance, the first generated volume world collection will not be automatically linked to the final set and it would miss the world volume. Which I think is better than rendering black world.

If a user opens a file with a linked scene, then no conversion happens and the world will render black.

In any case, I would expect this is something only happening in larger production pipelines where a pipeline TD will have to fix manually. But even then, EEVEE-Next is supposed to be disruptive, so I don't think users expect these complex cases to work without modifications.

A user can detect that something went wrong during conversion, but doesn't have a clue where it originates from.

There will be a report that a conversion happened. Making the user aware that there is modification.
The volume objects are visible in the outliner, making it possible to either fix or detect the conflict.

Hiding an operator somewhere add a burden on the user to make their file work (by default, not only for failure case) and adds a discoverability issue.

The data management of this design isn't defined and will be unclear to users what they need to do when something is incorrect.

The failure cases are:

  1. missing distant lighting (the current behavior) because linked scene not processed.
  2. missing volume shader because missing linked versionning collection.

The procedure for each would be:

  1. to open the linked world file, save it and reload the set file.
  2. link the volume versionning collection.

Which I think is not so bad.

There is plenty of area in the versioning code that just fails silently. We should make a report that indicates the world volume versioning failed. It think it is just a matter of communication. But that's the same issue as with the operator, the user have to take action and have to know what. But at least it is not for the common case.

A user can detect that something went wrong during conversion, but doesn't have a clue where it originates from. One reason why user data should only be changed via an operator.

Also we do these kind of destructive conversions quite often (node replacement, convert autosmooth to modifier, etc...). If they are documented and there is a notification, they are usually well received.

As this is part of the versioning, we now we need to support it for-ever. Although the code will typically be used in a short stretch of time.

We do increase the minimum blendfile version blender can load once in a while.

TL;DR

Doing the versioning only local worlds (not linked) will fix most cases while make it trivial to fix others.

> Development needs to be done in C/CPP which adds a different level of complexity, quality and maintainability. I share this concern. But even if the list of things to do is long, it isn't very hard to do for the most part. The only tricky part is dealing with nodetrees. > Users have different expectation when using linked scenes or worlds. Collections can be easily added to incorrect blend files and might also be created multiple times (in different blend files) changing the final pixel result. The main reason why we never alter user data during versioning. We should only convert worlds local to this file, which is safer for data management. This mean users will have to fix file in inclusion order. Which I think is sound. If a user opens an asset file that has a world volume, saves it, and then load a set file that link the world data block, in that instance, the first generated volume world collection will not be automatically linked to the final set and it would miss the world volume. Which I think is better than rendering black world. If a user opens a file with a linked scene, then no conversion happens and the world will render black. In any case, I would expect this is something only happening in larger production pipelines where a pipeline TD will have to fix manually. But even then, EEVEE-Next is supposed to be disruptive, so I don't think users expect these complex cases to work without modifications. > A user can detect that something went wrong during conversion, but doesn't have a clue where it originates from. There will be a report that a conversion happened. Making the user aware that there is modification. The volume objects are visible in the outliner, making it possible to either fix or detect the conflict. Hiding an operator somewhere add a burden on the user to make their file work (by default, not only for failure case) and adds a discoverability issue. > The data management of this design isn't defined and will be unclear to users what they need to do when something is incorrect. The failure cases are: 1. missing distant lighting (the current behavior) because linked scene not processed. 2. missing volume shader because missing linked versionning collection. The procedure for each would be: 1. to open the linked world file, save it and reload the set file. 2. link the volume versionning collection. Which I think is not so bad. There is plenty of area in the versioning code that just fails silently. We should make a report that indicates the world volume versioning failed. It think it is just a matter of communication. But that's the same issue as with the operator, the user have to take action and have to know what. But at least it is not for the common case. > A user can detect that something went wrong during conversion, but doesn't have a clue where it originates from. One reason why user data should only be changed via an operator. Also we do these kind of destructive conversions quite often (node replacement, convert autosmooth to modifier, etc...). If they are documented and there is a notification, they are usually well received. > As this is part of the versioning, we now we need to support it for-ever. Although the code will typically be used in a short stretch of time. We do increase the minimum blendfile version blender can load once in a while. #### TL;DR Doing the versioning only local worlds (not linked) will fix most cases while make it trivial to fix others.
Jeroen Bakker commented 2024-04-28 11:48:08 +02:00
Author
Member
Copy Link

If we only convert local data, than it most likely doesn't fit as part of versioning code. I am not aware of versioning code where we make this differentiation, I would prefer to have some approval from brecht/bastien about that, making sure we don't do something that needs to be rolled back because it has many issues.

I can imagine we add it to the append/open on a higher level, but it is also awkward due to the duration the code would commonly run.

For we also introduce 2 different results (link vs append) which is IMO bad.

The issue is that ID data blocks are user owned. Conversions you refer to happen within a data block so is fine and manageable.

If we only convert local data, than it most likely doesn't fit as part of versioning code. I am not aware of versioning code where we make this differentiation, I would prefer to have some approval from brecht/bastien about that, making sure we don't do something that needs to be rolled back because it has many issues. I can imagine we add it to the append/open on a higher level, but it is also awkward due to the duration the code would commonly run. For we also introduce 2 different results (link vs append) which is IMO bad. The issue is that ID data blocks are user owned. Conversions you refer to happen within a data block so is fine and manageable.
Clément Foucault commented 2024-04-28 12:51:02 +02:00
Member
Copy Link

@brecht @mont29 This is a very touchy topic about adding ID's during versioning and selectively do this from file local IDs (not linked). We need your insights.

@brecht @mont29 This is a very touchy topic about adding ID's during versioning and selectively do this from file local IDs (not linked). We need your insights.
Jeroen Bakker commented 2024-04-28 13:32:23 +02:00
Author
Member
Copy Link

Ow BTW I do think using a collection and how the ico sphere should be done is a good idea.

Ow BTW I do think using a collection and how the ico sphere should be done is a good idea.
Bastien Montagne commented 2024-04-28 14:05:41 +02:00
Owner
Copy Link

I would not accept a solution that handle half of the conversion problem automatically, and leaves the other half for the user to fix manually, in a cryptic and absolutely non-obvious way from Blender usage PoV (even if its clearly documented in the release notes - who reads them? ;) ).

I would also rather avoid the fully manual solution, as it would also most likely be dodgy (at best) in linking/appending cases.

I am not sure I understand why you want to skip linked data in your current proposal? We now (should!) have all the tooling to create 'virtual' linked data during versioning. You can see e.g. how GPv3 code now deals with the goenodetree it needs to create for the legacy GPv2 layer thickness adjustments (see offset_radius_node_tree_add() and its usage in grease_pencil_convert_legacy.cc). And the new EEVEE conversion code should almost certainly be called at the same places as blender::bke::greasepencil::convert::legacy_main().

I would not accept a solution that handle half of the conversion problem automatically, and leaves the other half for the user to fix manually, in a cryptic and absolutely non-obvious way from Blender usage PoV (even if its clearly documented in the release notes - who reads them? ;) ). I would also rather avoid the fully manual solution, as it would also most likely be dodgy (at best) in linking/appending cases. I am not sure I understand why you want to skip linked data in your current proposal? We now (should!) have all the tooling to create 'virtual' linked data during versioning. You can see e.g. how GPv3 code now deals with the goenodetree it needs to create for the legacy GPv2 layer thickness adjustments (see `offset_radius_node_tree_add()` and its usage in `grease_pencil_convert_legacy.cc`). And the new EEVEE conversion code should almost certainly be called at the same places as `blender::bke::greasepencil::convert::legacy_main()`.
Clément Foucault commented 2024-04-28 16:06:24 +02:00
Member
Copy Link

Ok, so if we do have a way to have virtual linked collections (and all the other needed datablocks), then I don't see any issue with linked scenes.

What happens in the case of a linked world in a scene that isn't linked? If we can add a linked (virtual) collection to the scene, then it would also fix the second problem.

The only thing I'm not sure about this is what happens if you have recursive linking. Does the versionning applies after all linking is done or is it done after each linking step? and would it affect the outcome?

Also I hope overrides are not possible on these versionned datablocks, otherwise that could become quite bad.

Also final issue, what about unused worlds (not used by any scenes)? Should we create collections for them too?

Ok, so if we do have a way to have virtual linked collections (and all the other needed datablocks), then I don't see any issue with linked scenes. What happens in the case of a linked **world** in a scene that isn't linked? If we can add a linked (virtual) collection to the scene, then it would also fix the second problem. The only thing I'm not sure about this is what happens if you have recursive linking. Does the versionning applies after all linking is done or is it done after each linking step? and would it affect the outcome? Also I hope overrides are not possible on these versionned datablocks, otherwise that could become quite bad. Also final issue, what about unused worlds (not used by any scenes)? Should we create collections for them too?
Bastien Montagne commented 2024-04-28 16:58:07 +02:00
Owner
Copy Link

What happens in the case of a linked world in a scene that isn't linked? If we can add a linked (virtual) collection to the scene, then it would also fix the second problem.

Yes once created, these linked IDs behave like any other linked IDs, so you can use them in your local data as well. The only thing is that they do not exist, on next file read, their local usages will be reset to nullptr, and they will be re-generated afterwards.

The only thing I'm not sure about this is what happens if you have recursive linking. Does the versioning applies after all linking is done or is it done after each linking step? and would it affect the outcome?

This versioning (from do_version_after_setup()) applies at the end of the readfile process, once every thing has been read, linked, and the more 'basic' doversion has been done. In other words, on the Main data-base is fully 'ready'.

Also I hope overrides are not possible on these versionned datablocks, otherwise that could become quite bad.

They are. But they would be useless, since these generated linked data are re-created after liboverride is applied in readfile process. It might be worth adding a runtime tag to these virtual linked IDs to prevent that kind of thing actually... We could also prevent showing them in the list of usable IDs altogether (similar to @brecht idea to filter out some IDs from the 'immediately user-visible' ones).

Also final issue, what about unused worlds (not used by any scenes)? Should we create collections for them too?

That I don't know... Creating the collection is fine, but then how would the user know that they have to add it to their viewlayer when they decide to use the matching world?

> What happens in the case of a linked **world** in a scene that isn't linked? If we can add a linked (virtual) collection to the scene, then it would also fix the second problem. Yes once created, these linked IDs behave like any other linked IDs, so you can use them in your local data as well. The only thing is that they do not exist, on next file read, their local usages will be reset to `nullptr`, and they will be re-generated afterwards. > The only thing I'm not sure about this is what happens if you have recursive linking. Does the versioning applies after all linking is done or is it done after each linking step? and would it affect the outcome? This versioning (from `do_version_after_setup()`) applies at the end of the readfile process, once every thing has been read, linked, and the more 'basic' doversion has been done. In other words, on the Main data-base is fully 'ready'. > Also I hope overrides are not possible on these versionned datablocks, otherwise that could become quite bad. They are. But they would be useless, since these generated linked data are re-created after liboverride is applied in readfile process. It might be worth adding a runtime tag to these virtual linked IDs to prevent that kind of thing actually... We could also prevent showing them in the list of usable IDs altogether (similar to @brecht idea to filter out some IDs from the 'immediately user-visible' ones). > Also final issue, what about unused worlds (not used by any scenes)? Should we create collections for them too? That I don't know... Creating the collection is fine, but then how would the user know that they have to add it to their viewlayer when they decide to use the matching world?
👍 1
Jeroen Bakker commented 2024-04-29 08:26:44 +02:00
Author
Member
Copy Link

Virtual collections solves most issues. Manual steps are needed when considering conversion order. In case of grease pencil this might not have been an issue as it is all part of the same ID.

In case we link directly to a world. And the file containing the world is converted. Any file linking to that world (converted or not), doesn't know which collection to include. Storing a ref in the world cannot work as the versioning code will not be triggered anymore.

A limitation is that world assets will look different (when dragged/dropped) before and after the conversion.

Seems to be a similar case that Bastien mentions in previous post, except that it can happens for any worlds.

So perhaps the decision is how we inform the user. Of course release-notes. But it is hard to communicate it when the user need to act. Asset libraries can be altered by someone else.

Virtual collections solves most issues. Manual steps are needed when considering conversion order. In case of grease pencil this might not have been an issue as it is all part of the same ID. In case we link directly to a world. And the file containing the world is converted. Any file linking to that world (converted or not), doesn't know which collection to include. Storing a ref in the world cannot work as the versioning code will not be triggered anymore. A limitation is that world assets will look different (when dragged/dropped) before and after the conversion. Seems to be a similar case that Bastien mentions in previous post, except that it can happens for any worlds. So perhaps the decision is how we inform the user. Of course release-notes. But it is hard to communicate it when the user need to act. Asset libraries can be altered by someone else.
Brecht Van Lommel commented 2024-04-29 10:32:01 +02:00
Owner
Copy Link

My advice would be to not add any versioning or operator, and accept the compatibility breakage. I don't think all this complexity is worth it.

My advice would be to not add any versioning or operator, and accept the compatibility breakage. I don't think all this complexity is worth it.
👎 1 ❤️ 1
Donovane commented 2024-04-29 12:33:35 +02:00
First-time contributor
Copy Link

My advice would be to not add any versioning or operator, and accept the compatibility breakage. I don't think all this complexity is worth it.

Not agree with you in future blender vesions this thing can be needed !

> My advice would be to not add any versioning or operator, and accept the compatibility breakage. I don't think all this complexity is worth it. Not agree with you in future blender vesions this thing can be needed !
Clément Foucault commented 2024-04-30 19:14:04 +02:00
Member
Copy Link

I had a discussion with @dfelinto on the subject. He mentioned that we had this issue of adding manual conversion in the past. Apparently this was done by adding the operator in the help menu in the top bar. I don't know if this still fits nowadays UI guidelines but that sounds a good location for it.

I don't think just accepting the breakage without an easy way to fix the file is the best option. Even if we document it, the steps to make a file work are quite involved. So I would still think an operator is kind of a good compromise. We can just link to it in the release notes (instead of listing a whole complex procedure).

I had a discussion with @dfelinto on the subject. He mentioned that we had this issue of adding manual conversion in the past. Apparently this was done by adding the operator in the help menu in the top bar. I don't know if this still fits nowadays UI guidelines but that sounds a good location for it. I don't think just accepting the breakage without an easy way to fix the file is the best option. Even if we document it, the steps to make a file work are quite involved. So I would still think an operator is kind of a good compromise. We can just link to it in the release notes (instead of listing a whole complex procedure).
Brecht Van Lommel commented 2024-04-30 19:59:27 +02:00
Owner
Copy Link

I'm not sure there's really a good place to make that kind of operator discoverable. If we can make the operator only appear when there is known to be an old world volume in the file, it can be more prominent. But still I don't know if anyone would look in the Help menu for that.

If we are going to have to guide users to it through release notes and docs, maybe it is best to put it in a logical place, like the shader editor header when a world is selected there, and the volume panel in the world properties editor.

I'm not sure there's really a good place to make that kind of operator discoverable. If we can make the operator only appear when there is known to be an old world volume in the file, it can be more prominent. But still I don't know if anyone would look in the Help menu for that. If we are going to have to guide users to it through release notes and docs, maybe it is best to put it in a logical place, like the shader editor header when a world is selected there, and the volume panel in the world properties editor.
Clément Foucault commented 2024-04-30 20:23:23 +02:00
Member
Copy Link

If we can make the operator only appear when there is known to be an old world volume in the file, it can be more prominent.

The thing is, this is not trivial. Except if we know from which blendfile version the datablock is.

> If we can make the operator only appear when there is known to be an old world volume in the file, it can be more prominent. The thing is, this is not trivial. Except if we know from which blendfile version the datablock is.
Brecht Van Lommel commented 2024-04-30 22:44:31 +02:00
Owner
Copy Link

We can add a flag to the world datablock in versioning for that?

We can add a flag to the world datablock in versioning for that?
Merge conflict checking is in progress. Try again in few moments.
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u eevee-next/convert-world-volume:Jeroen-Bakker-eevee-next/convert-world-volume
git checkout Jeroen-Bakker-eevee-next/convert-world-volume
Sign in to join this conversation.
Reviewers
No reviewers
Pablo Vazquez
Clément Foucault
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
4.2 LTS
Projects
Clear projects
No project
EEVEE & Viewport
Assignees
Clear assignees
No Assignees
Jeroen Bakker
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#119734
No description provided.
Delete Branch "Jeroen-Bakker/blender:eevee-next/convert-world-volume"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?