Good Morning, I've been trying out the volume render, with a lot of success. However, while I was starting to work on rotating the view, I found the normal vectors aligned with x, y or z would create blank images. After reading what was printed on the console, I saw that the volume being rendered had zero width in two dimensions: yt INFO 2010-07-29 08:31:28,740 Traversing 17583 bricks between [ 0.45 0.5 0.5 ] and [ 0.55 0.5 0.5 ] I tried looking into extension/volume_rendering/camera.py last night, in particular _setup_normalized_vectors, but the body and mind were weak. I'll keep trying, but if anyone has suggestions, or corrections to my method, they would be appreciated. Rendering script at http://paste.enzotools.org/show/958/ Thanks, Rick
Hi Rick, I think I agree with your assessment, it's in the setup_normalized_vectors. What I think is happening is that my guess for a north vector (if unsupplied, and I don't know about anybody else but I never supply a north vector ...) is resulting in it getting zero for the other unit vectors. Would you be able to see what the value of cam.north_vector is in your script? What we might also want to do is just add some jitter to the estimate for a North vector, which might be able to help it. Inside setup_normalized_vectors, if you change the original: if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector, vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel() to something like: if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector + [1e-9, 0.0, 0.0], vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel() it might have some (good?) effect. I think Sam has an alternate mechanism for estimating a north vector that might fix this, too.. -Matt On Thu, Jul 29, 2010 at 7:58 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Good Morning,
I've been trying out the volume render, with a lot of success. However, while I was starting to work on rotating the view, I found the normal vectors aligned with x, y or z would create blank images. After reading what was printed on the console, I saw that the volume being rendered had zero width in two dimensions:
yt INFO 2010-07-29 08:31:28,740 Traversing 17583 bricks between [ 0.45 0.5 0.5 ] and [ 0.55 0.5 0.5 ]
I tried looking into extension/volume_rendering/camera.py last night, in particular _setup_normalized_vectors, but the body and mind were weak. I'll keep trying, but if anyone has suggestions, or corrections to my method, they would be appreciated.
Rendering script at http://paste.enzotools.org/show/958/
Thanks, Rick
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi, I've never worked with a North vector, but I know Andy Cunningham has, and I know he patched the source to allow some flexibility with this. I don't remember exactly what he did, but you might consider asking him. j On Thu, Jul 29, 2010 at 8:14 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Rick,
I think I agree with your assessment, it's in the setup_normalized_vectors. What I think is happening is that my guess for a north vector (if unsupplied, and I don't know about anybody else but I never supply a north vector ...) is resulting in it getting zero for the other unit vectors. Would you be able to see what the value of cam.north_vector is in your script?
What we might also want to do is just add some jitter to the estimate for a North vector, which might be able to help it. Inside setup_normalized_vectors, if you change the original:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector, vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
to something like:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector + [1e-9, 0.0, 0.0], vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
it might have some (good?) effect. I think Sam has an alternate mechanism for estimating a north vector that might fix this, too..
-Matt On Thu, Jul 29, 2010 at 7:58 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Good Morning,
I've been trying out the volume render, with a lot of success. However, while I was starting to work on rotating the view, I found the normal vectors aligned with x, y or z would create blank images. After reading what was printed on the console, I saw that the volume being rendered had zero width in two dimensions:
yt INFO 2010-07-29 08:31:28,740 Traversing 17583 bricks between [ 0.45 0.5 0.5 ] and [ 0.55 0.5 0.5 ]
I tried looking into extension/volume_rendering/camera.py last night, in particular _setup_normalized_vectors, but the body and mind were weak. I'll keep trying, but if anyone has suggestions, or corrections to my method, they would be appreciated.
Rendering script at http://paste.enzotools.org/show/958/
Thanks, Rick
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- ---------------- i am dot org: www.jsoishi.org
Hi Matt & Jeff, No luck on perturbing the North vector. I think the problem may be in the front and back centers that are used to calculate the volume. These get multiplied by the normal vector, and if that has zero components, you get no box: self.back_center = self.center - 0.5*self.width[0]*self.unit_vectors[2] self.front_center = self.center + 0.5*self.width[0]*self.unit_vectors[2] Looking at these values gives: [ 0.45 0.5 0.5 ] [ 0.55 0.5 0.5 ] --Rick On Jul 29, 2010, at 9:19 AM, j s oishi wrote:
Hi,
I've never worked with a North vector, but I know Andy Cunningham has, and I know he patched the source to allow some flexibility with this. I don't remember exactly what he did, but you might consider asking him.
j
On Thu, Jul 29, 2010 at 8:14 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Rick,
I think I agree with your assessment, it's in the setup_normalized_vectors. What I think is happening is that my guess for a north vector (if unsupplied, and I don't know about anybody else but I never supply a north vector ...) is resulting in it getting zero for the other unit vectors. Would you be able to see what the value of cam.north_vector is in your script?
What we might also want to do is just add some jitter to the estimate for a North vector, which might be able to help it. Inside setup_normalized_vectors, if you change the original:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector, vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
to something like:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector + [1e-9, 0.0, 0.0], vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
it might have some (good?) effect. I think Sam has an alternate mechanism for estimating a north vector that might fix this, too..
-Matt On Thu, Jul 29, 2010 at 7:58 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Good Morning,
I've been trying out the volume render, with a lot of success. However, while I was starting to work on rotating the view, I found the normal vectors aligned with x, y or z would create blank images. After reading what was printed on the console, I saw that the volume being rendered had zero width in two dimensions:
yt INFO 2010-07-29 08:31:28,740 Traversing 17583 bricks between [ 0.45 0.5 0.5 ] and [ 0.55 0.5 0.5 ]
I tried looking into extension/volume_rendering/camera.py last night, in particular _setup_normalized_vectors, but the body and mind were weak. I'll keep trying, but if anyone has suggestions, or corrections to my method, they would be appreciated.
Rendering script at http://paste.enzotools.org/show/958/
Thanks, Rick
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- ---------------- i am dot org: www.jsoishi.org _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Rick, I think traversing between those points is okay... I just tested and the bug is only in hg. I'll track it down ASAP, but I have to take care of some other things right now and wanted to let you know that SVN should work okay. -Matt On Thu, Jul 29, 2010 at 8:22 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Hi Matt & Jeff,
No luck on perturbing the North vector. I think the problem may be in the front and back centers that are used to calculate the volume. These get multiplied by the normal vector, and if that has zero components, you get no box:
self.back_center = self.center - 0.5*self.width[0]*self.unit_vectors[2] self.front_center = self.center + 0.5*self.width[0]*self.unit_vectors[2]
Looking at these values gives: [ 0.45 0.5 0.5 ] [ 0.55 0.5 0.5 ]
--Rick
On Jul 29, 2010, at 9:19 AM, j s oishi wrote:
Hi,
I've never worked with a North vector, but I know Andy Cunningham has, and I know he patched the source to allow some flexibility with this. I don't remember exactly what he did, but you might consider asking him.
j
On Thu, Jul 29, 2010 at 8:14 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Rick,
I think I agree with your assessment, it's in the setup_normalized_vectors. What I think is happening is that my guess for a north vector (if unsupplied, and I don't know about anybody else but I never supply a north vector ...) is resulting in it getting zero for the other unit vectors. Would you be able to see what the value of cam.north_vector is in your script?
What we might also want to do is just add some jitter to the estimate for a North vector, which might be able to help it. Inside setup_normalized_vectors, if you change the original:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector, vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
to something like:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector + [1e-9, 0.0, 0.0], vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
it might have some (good?) effect. I think Sam has an alternate mechanism for estimating a north vector that might fix this, too..
-Matt On Thu, Jul 29, 2010 at 7:58 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Good Morning,
I've been trying out the volume render, with a lot of success. However, while I was starting to work on rotating the view, I found the normal vectors aligned with x, y or z would create blank images. After reading what was printed on the console, I saw that the volume being rendered had zero width in two dimensions:
yt INFO 2010-07-29 08:31:28,740 Traversing 17583 bricks between [ 0.45 0.5 0.5 ] and [ 0.55 0.5 0.5 ]
I tried looking into extension/volume_rendering/camera.py last night, in particular _setup_normalized_vectors, but the body and mind were weak. I'll keep trying, but if anyone has suggestions, or corrections to my method, they would be appreciated.
Rendering script at http://paste.enzotools.org/show/958/
Thanks, Rick
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- ---------------- i am dot org: www.jsoishi.org _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, Thanks for getting back to me. I'll work from SVN for now. I tried bumping the limits of the front and back centers, and that didn't help, so the problem must be elsewhere. It does happen when any component of the normal vector is non-equal, e.g., [0.2, 0.5, 0.5] is bad. --Rick On Jul 29, 2010, at 9:45 AM, Matthew Turk wrote:
Hi Rick,
I think traversing between those points is okay... I just tested and the bug is only in hg. I'll track it down ASAP, but I have to take care of some other things right now and wanted to let you know that SVN should work okay.
-Matt
On Thu, Jul 29, 2010 at 8:22 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Hi Matt & Jeff,
No luck on perturbing the North vector. I think the problem may be in the front and back centers that are used to calculate the volume. These get multiplied by the normal vector, and if that has zero components, you get no box:
self.back_center = self.center - 0.5*self.width[0]*self.unit_vectors[2] self.front_center = self.center + 0.5*self.width[0]*self.unit_vectors[2]
Looking at these values gives: [ 0.45 0.5 0.5 ] [ 0.55 0.5 0.5 ]
--Rick
On Jul 29, 2010, at 9:19 AM, j s oishi wrote:
Hi,
I've never worked with a North vector, but I know Andy Cunningham has, and I know he patched the source to allow some flexibility with this. I don't remember exactly what he did, but you might consider asking him.
j
On Thu, Jul 29, 2010 at 8:14 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Rick,
I think I agree with your assessment, it's in the setup_normalized_vectors. What I think is happening is that my guess for a north vector (if unsupplied, and I don't know about anybody else but I never supply a north vector ...) is resulting in it getting zero for the other unit vectors. Would you be able to see what the value of cam.north_vector is in your script?
What we might also want to do is just add some jitter to the estimate for a North vector, which might be able to help it. Inside setup_normalized_vectors, if you change the original:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector, vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
to something like:
if north_vector is None: vecs = na.identity(3) t = na.cross(normal_vector + [1e-9, 0.0, 0.0], vecs).sum(axis=1) ax = t.argmax() north_vector = na.cross(vecs[ax,:], normal_vector).ravel()
it might have some (good?) effect. I think Sam has an alternate mechanism for estimating a north vector that might fix this, too..
-Matt On Thu, Jul 29, 2010 at 7:58 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Good Morning,
I've been trying out the volume render, with a lot of success. However, while I was starting to work on rotating the view, I found the normal vectors aligned with x, y or z would create blank images. After reading what was printed on the console, I saw that the volume being rendered had zero width in two dimensions:
yt INFO 2010-07-29 08:31:28,740 Traversing 17583 bricks between [ 0.45 0.5 0.5 ] and [ 0.55 0.5 0.5 ]
I tried looking into extension/volume_rendering/camera.py last night, in particular _setup_normalized_vectors, but the body and mind were weak. I'll keep trying, but if anyone has suggestions, or corrections to my method, they would be appreciated.
Rendering script at http://paste.enzotools.org/show/958/
Thanks, Rick
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- ---------------- i am dot org: www.jsoishi.org _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
j s oishi -
Matthew Turk -
Rick Wagner