Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1505 closed defect (not a bug)

Surface capping and Side View both wrong

Reported by: olibclarke@… Owned by: Tom Goddard
Priority: normal Milestone: 1.0
Component: Surface Version:
Keywords: Cc: Greg Couch
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

The following bug report has been submitted:
Platform:        Darwin-18.2.0-x86_64-i386-64bit
ChimeraX Version: 0.8 (2018-12-06)
Description
Hi,

The position of the near clipping plane as represented in the Side View does not seem to correspond to the graphics window. You can see in the attached screenshot - it shouldn't be clipping the front but it is.

Cheers
Oli



Log:
> camera ortho

> lighting soft

> cofr centerOfView

UCSF ChimeraX version: 0.8 (2018-12-06)  
How to cite UCSF ChimeraX  

> open cryosparc_P30_J165_004_sharp.mrc

Opened cryosparc_P30_J165_004_sharp.mrc, grid size 350,350,350, pixel 1.19,
shown at level 3.32, step 2, values float32  

> color #1 cornflower blue

> turn z 70

> turn z -1

> turn z -10

> turn z 5

> zoom 1.1

> zoom 1.1

> zoom 1.1

> zoom 1.1

> zoom 1.1

> view cofr false

> view cofr false

> zoom 1.1

> zoom 1.1

> zoom 1.1

> lighting soft

> lighting full

> lighting soft

> set silhouettes true

> surface

No atomic models open.  

Expected an atoms specifier or a keyword  

> help surface

> surface dust #1 size 100

> toolshed show "Side View"

> lighting depthCueColor white

> lighting depthCueColor black

> lighting depthCueColor white

> lighting depthCueStart 0.2 depthCueEnd 1

> lighting depthCueStart 0 depthCueEnd 1

Invalid "depthCueStart" argument: Expected a number  

> lighting depthCueStart 0.1 depthCueEnd 1

> lighting depthCueStart 0.2 depthCueEnd 1

> lighting depthCueStart 0.3 depthCueEnd 1

> lighting depthCueStart 0.3 depthCueEnd 1

> save image /Users/oliverclarke/Dropbox/Downloads/Tg_top.png width 2000
height 2000 supersample 4

> turn x -90

> turn y -90

Expected a keyword  

> clip

> ~clip




OpenGL version: 4.1 ATI-2.2.8
OpenGL renderer: AMD Radeon Pro 580 OpenGL Engine
OpenGL vendor: ATI Technologies Inc.
File attachment: Screen Shot 2018-12-06 at 5.07.44 PM.png

Screen Shot 2018-12-06 at 5.07.44 PM.png

Attachments (1)

Screen Shot 2018-12-06 at 5.07.44 PM.png (3.5 MB ) - added by olibclarke@… 7 years ago.
Added by email2trac

Change History (6)

by olibclarke@…, 7 years ago

Added by email2trac

in reply to:  2 comment:1 by olibclarke@…, 7 years ago

Also there is no cap on the clipped region, even though I have `surface cap true` set

Cheers
Oli


comment:2 by Eric Pettersen, 7 years ago

Cc: Greg Couch added
Component: UnassignedSurface
Milestone: 1.0
Owner: set to Tom Goddard
Platform: all
Project: ChimeraX
Status: newassigned
Summary: ChimeraX bug report submissionSurface capping and Side View both wrong

comment:3 by Tom Goddard, 7 years ago

Resolution: not a bug
Status: assignedclosed

This is a bit weird but I don't think there is any bug here and the screenshot shows what the situation is.

You have the eye (= camera) positioned between the near and far clip planes. So the hole you see is because part of the map is behind the camera. But there is no clip plane there -- the near clip plane is behind the eye which is what Side View correctly shows.

How you achieved this isn't totally clear from the commands, but I have a guess, and this reproduces it for me. You open a map, set the contour level very high so the surface is just a small blob, then do "view cofr false" (which appears in your log) which puts the camera right in front of the small blob. Then you lower the contour level so the new bigger surface passes behind the camera.

It might be that a surface cap should appear at the eye position when it is in front of the near clip plane, but I'm not keen on doing that.

In general ortho camera mode is weird, tricky and problematic. The distance of the camera from the model is irrelevant as long as all models are in front of the camera. So what distance should be used? The camera needs to have a position in 3-space. No matter what position you choose, the user can open new models or increase the size of a surface on a map, and now part of it is behind the camera. I think it is a bad idea to be automatically moving the camera when model display changes, although it seems that would be necessary to make ortho work better.

I don't see anything to fix here.

in reply to:  5 comment:4 by olibclarke@…, 7 years ago

Hmmm fair enough Tom, although as one of the oddballs who prefers orthographic projection it makes me sad - but if I get into this situation how do I resolve it? Dragging the eye doesn’t seem to do anything in this situation.

I didn’t actually run `view cofr false` (or at least I didn’t type it in), so I’m not sure how that ended up in my log - it’s not in my startup commands either so I’m not sure where it came from

Cheers
Oli


comment:5 by Tom Goddard, 7 years ago

The toolbar icon with the mountains that centers the model runs "view cofr false". Most or all of the toolbar icons runs equivalent commands that are shown in the log.

Pressing that icon again fixes the problem since it places the camera so all models are in front and fit in the view. Also the "view" command typed to the command-line would do it. And the Actions menu will when it gets added to ChimeraX have the "Focus" operation which does the same.

Note: See TracTickets for help on using tickets.