topic Re: HPRISM_ & Top edge visibility in Libraries & objects

HPRISM_ & Top edge visibility

Anonymous — Mon, 26 Oct 2009 19:34:21 GMT

This is an old feature, which I always found annoying.
For the first solution (Left), top contour edges don't show in elevation.
Am I missing something?

Cheers

	R   = 0.2
	mat = SYMB_MAT
	
	for k = 1 to 2
		body -1
		s = 11 + 4*(k=2) + 64
	
		hprism_  mat, mat, mat, mat,
			10, 1, 0, R*0.5, 1,
			R  , 0  , s,
			1-R, 0  , s,
			1  , R  , s+1000,
			1  , 1-R, s,
			1-R, 1  , s+1000,
			R  , 1  , s,
			0  , 1-R, s+1000,
			0  , R  , s,
			R  , 0  , s+1000,
			R  , 0  ,-1

		addx 1.5
	next k
		del 2

Re: HPRISM_ & Top edge visibility

Anonymous — Mon, 26 Oct 2009 20:15:58 GMT

No, you are not missing something. I always check with this code, because these status codes always confuse me

   R   = 0.2
   mat = SYMB_MAT
   
   for s = 1 to 99
      body -1
    
      hprism_  mat, mat, mat, mat,
         10, 1, 0, R*0.5, 1,
         R  , 0  , s,
         1-R, 0  , s,
         1  , R  , s+1000,
         1  , 1-R, s,
         1-R, 1  , s+1000,
         R  , 1  , s,
         0  , 1-R, s+1000,
         0  , R  , s,
         R  , 0  , s+1000,
         R  , 0  ,-1

      addx 1.5
   next k

But I have a dirty fix for you:

   R   = 0.2
   mat = SYMB_MAT
   
IF GLOB_CONTEXT=4 THEN
	k=2
ELSE
	k=1
ENDIF

      body -1
      s = 11 + 4*(k=2) + 64
   
      hprism_  mat, mat, mat, mat,
         10, 1, 0, R*0.5, 1,
         R  , 0  , s,
         1-R, 0  , s,
         1  , R  , s+1000,
         1  , 1-R, s,
         1-R, 1  , s+1000,
         R  , 1  , s,
         0  , 1-R, s+1000,
         0  , R  , s,
         R  , 0  , s+1000,
         R  , 0  ,-1

Re: HPRISM_ & Top edge visibility

Anonymous — Mon, 26 Oct 2009 21:18:06 GMT

Master wrote:
No, you are not missing something. I always check with this code, because these status codes always confuse me

But I have a dirty fix for you:

I'm aware of these "global_context" workarounds. I'm not satified with them.
In case of object rotation (x, y, z), it can't be a solution.
I still have to add a parameter to control (manually) the mask value, in function of the rotation, which is not predictable.

I would like a fix, not a workaround.

There is always the solution to deal with GDL primitives (vert, edge, pgon). What a pain.
It defeats the purpose of this tool.

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 00:01:44 GMT

It's because one instance is s = 11 + 4 + 64 and all else s = 11 + 8 + 64

k is a variable and increases with each for/next and at this point it is still 1 to 2.

for k = 1 to 2 step 1
s = 11 + 4 + 64

HTH

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 07:01:54 GMT

Jeffrey wrote:
It's because one instance is s = 11 + 4 + 64 and all else s = 11 + 8 + 64

k is a variable and increases with each for/next and at this point it is still 1 to 2.

for k = 1 to 2 step 1
s = 11 + 4 + 64

HTH

Sorry, I don't think so. My status code just means 11+64 (first) , and 15+64 (second).
"step 1", is the default setting, thus it is implicit. No need to write it.

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 09:37:15 GMT

Olivier wrote:
This is an old feature, which I always found annoying.

You are right Olivier... This "feature" must be fixed.

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 13:35:44 GMT

Olivier wrote:

Sorry, I don't think so. My status code just means 11+64 (first) , and 15+64 (second).
"step 1", is the default setting, thus it is implicit. No need to write it.

Regardless of what you think the computer disagrees. While you will get no argument about the inconsistencies of the status and mask values from me. The math in GDL, however inaccurate, is consistent. 14 + 64 would be (11+(4*1)) +64 and you are our of luck with 15 because if and when k =2, which it does only after the first instance of the object you get 19 provided it is written correctly or you get 8 the way you have written it.

I write step out of habit just as I remove all the transformations in a for/next loop. Because DEL 1 doesn't remove them efficiently.

good luck

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 17:51:39 GMT

Jeffrey wrote:
Regardless of what you think the computer disagrees. While you will get no argument about the inconsistencies of the status and mask values from me. The math in GDL, however inaccurate, is consistent. 14 + 64 would be (11+(4*1)) +64 and you are our of luck with 15 because if and when k =2, which it does only after the first instance of the object you get 19 provided it is written correctly or you get 8 the way you have written it.

I don't follow you.

	for k = 1 to 2
		s = 11 + 4*(k=2) + 64
		print s
	next k

It returns 75 and 79. All is fine.

My remark was about status code 11+64 (75). I don't want 15+64 (79).
64*j7 controls the viewpoint dependent visibility of the current vertical edge.
I was wondering about a similar feature for the horizontal top edge visibility.

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 19:42:56 GMT

Olivier wrote:
Jeffrey wrote:
Regardless of what you think the computer disagrees. While you will get no argument about the inconsistencies of the status and mask values from me. The math in GDL, however inaccurate, is consistent. 14 + 64 would be (11+(4*1)) +64 and you are our of luck with 15 because if and when k =2, which it does only after the first instance of the object you get 19 provided it is written correctly or you get 8 the way you have written it.
I don't follow you.
	for k = 1 to 2
		s = 11 + 4*(k=2) + 64
		print s
	next k
It returns 75 and 79. All is fine.

My remark was about status code 11+64 (75). I don't want 15+64 (79).
64*j7 controls the viewpoint dependent visibility of the current vertical edge.
I was wondering about a similar feature for the horizontal top edge visibility.

Wow, You have serious accuracy issues then.

If it returns 75 and 79 and "all is fine" but you don't want 79 then how can all be fine?

Further status codes are binary and not cumulative ( i.e.11+4*(k=2)+64 does not equal 79, 83 or even 75.

I would be most concerned with the inaccuracy issues you are having because if k =2 then 4*k = 8 therefor 11+8+64 = 83 (19+64) and when k-1, which it does in the first instance, 4*k =4 so 11+4+64 = 79 (15+64) which of course you don't want.

I thought adding 1/64" to each item in the transformation stacks was a problem.

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 20:08:48 GMT

Jeffrey wrote:
Wow, You have serious accuracy issues then.

Are you joking?

Better to stop here.

Cheers

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 20:36:46 GMT

Jeffrey,

I guess you misunderstood the code...

The "(k=2)" acts like a switch... if k=2 it returns 1 else its zero.

So... only in the second step (k=2) the status code 4 is added.

HTH.

Re: HPRISM_ & Top edge visibility

Anonymous — Tue, 27 Oct 2009 21:07:41 GMT

Braza wrote:
Jeffrey,

I guess you misunderstood the code...

The "(k=2)" acts like a switch... if k=2 it returns 1 else its zero.

So... only in the second step (k=2) the status code 4 is added.

HTH.

I did. My apologies. I also misunderstood what I have been told about mask and status values not being cumulative as well or that the computer reads them differently although I still get different result between 2+4 or 6. Now that I understand the switch I guess I don't understand the point of it returns an undesired result.

Re: HPRISM_ & Top edge visibility

Anonymous — Wed, 28 Oct 2009 10:22:28 GMT

Hi Jeffrey,

In other words...

s = 11 + 4*(k=2) + 64

is a more elegant way of scripting

if k = 1 then s = 11 + 64
if k = 2 then s = 11 + 4 + 64

if k = 1 then s = 75
if k = 2 then s = 79

Edit: Anyway... Its a pity to see a great command compromised by such an unwanted feature...

It would be nice to hear some feedback from GS about this issue.