HPRISM_ & Top edge visibility

[Anonymous]

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

[Anonymous]

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

[Anonymous]

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.

[Anonymous]

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

[Anonymous]

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.

[Anonymous]

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

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

[Anonymous]

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

[Anonymous]

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.

[Anonymous]

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.

[Anonymous]

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

Are you joking?

Better to stop here.

Cheers