ANARI #20303
ANARI #20303
Conversation
|
@griffin28 haven't forgotten. Have a few outstanding PRs to get to. Will likely get to by tomorrow PM. |
Fix calls to bv_ensure_built_or_ready. Add ensure_built_or_ready_component to test for existence of individual libs/components. Modified bv_xcb to use ensure_built_or_ready_component.
* Remove ultrawrapper. * Remove pyparsing from list of TP downloads.
…hed`. (#20322) Reason: textChanged is a signal emitted with every keystroke. In most instances we only want the signal when all text has been entered. There are a few exceptions: QLineEdit with validator attached, or a `search` widget that updates displayed contents as user types. Those instances were not modified.
Fixed issues causing test to fail. Removed associated moab test from skip list.
|
My apologies @markcmiller86 and @biagas I did a rebase on the latest changes from develop before I pushed my updates. I should've waited until the review was done because now it's showing all of those other commits (137 files changed!!). |
|
The first commit will have all the files I've actually touched and the last commit will have the current updates based on @biagas feedback. |
Sometimes a merge-from-develop into the branch works better than a rebase. No worries, it still workable. |
There was a problem hiding this comment.
@griffin28 I am about 1/2 way through and will push the Submit review button now with a handful of remarks so far. Will finish up next week.
There was a problem hiding this comment.
I notice we have one of these for Ospray too. What is driving the need for axis actors for these scenarios...translating camera info to the form needed in the renderer?
| @@ -316,12 +315,17 @@ avtViewInfo::SetCameraFromView(vtkCamera *vtkcam) const | |||
| vtkcam->SetWindowCenter(2.0*imagePan[0], 2.0*imagePan[1]); | |||
| vtkcam->SetFocalDisk(imageZoom); | |||
|
|
|||
| #ifdef HAVE_ANARI | |||
There was a problem hiding this comment.
This block seems a tad funky...we're testing for anari at compile time but ospray at run time. Does that mean that if VisIt is compiled with ANARI, that ANARI is always on? For ospray, I think it can be enabled and disabled at run time too.
There was a problem hiding this comment.
This is an attributes object. So, I am not sure we support conditionally compiled members here but there are a ton of things related to Anari here that, in theory anyways, should only be there if anari is being used.
I wonder if it makes sense to make an AttributeGroup submember of this object that holds all the anari stuff and that whole subobject is conditionally compil
There was a problem hiding this comment.
Ok @griffin28 I've finished all the files.
@biagas I am wondering about a couple of cases here where the Anari controls, which number around 40, are put at the same level as other, similar controls (RenderingAttributes, VisWindow). On the one hand, this makes perfect sense semantically. On the other hand, I wonder if the right thing to do is create a sub-object of some kind for these to better isolate them to their own pieces.
I am not sure what you are questioning/suggesting. |
Repeating the last sentence in my remark... I wonder if the right thing to do is create a sub-object of some kind for these slew of Anari controls cases to better isolate them to their own pieces. |
Description
Resolves #18416
Add new surface rendering capability using ANARI. Note, this PR doesn't include the dynamic UI work since the code to support it is currently on VTK's master branch. Talked with Kitware and they said it will be in the VTK 9.5.0 release targeted for the summer 2025.
Type of change
[ ] Bug fix[ ] OtherHow Has This Been Tested?
CoefPressureReminders:
Checklist:
[ ] I have added debugging support to my changes.[ ] I have added tests that prove my fix is effective or that my feature works.[ ] I have added new baselines for any new tests to the repo.