Visual errors in edit mode #1

Open
secretrobotron opened this Issue Jul 16, 2012 · 7 comments

Projects

None yet

3 participants

@secretrobotron
Collaborator

Using the editor in the fourth example on the test maps page (http://www.syntensity.com/static/night12/) produces some serious visual glitches on OSX firefox nightly. The glitches aren't present in the third example, so perhaps the extra memory or processing demand causes it to buckle.

https://dl.dropbox.com/u/7054348/Screen%20Shot%202012-07-16%20at%2010.49.41%20AM.png

Just flying around will cause geometry to appear/disappear randomly. Sometimes, I needn't even move -- just press E and watch it freak out.

@kripken
Owner
kripken commented Jul 16, 2012

I can confirm this. It only happens in the largest map for some reason.

@cronos3k
Collaborator

Hello Bobby Richter

The editor and the PVS Culling (
http://sauerbraten.org/docs/editref.html#pvs_culling ) are not working well
altogether. So when using E for ending on a map with PVS on there is a high
chance of errors in the view. Use “clearpvs” command in the command lien
and it should work.

Greetings

Gregor

On Mon, Jul 16, 2012 at 7:21 PM, Bobby Richter <
reply@reply.github.com

wrote:

Using the editor in the fourth example on the test maps page (
http://www.syntensity.com/static/night12/) produces some serious visual
glitches on OSX firefox nightly. The glitches aren't present in the third
example, so perhaps the extra memory or processing demand causes it to
buckle.

https://dl.dropbox.com/u/7054348/Screen%20Shot%202012-07-16%20at%2010.49.41%20AM.png

Just flying around will cause geometry to appear/disappear randomly.
Sometimes, I needn't even move -- just press E and watch it freak out.


Reply to this email directly or view it on GitHub:
#1

@secretrobotron
Collaborator

Perhaps the clearpvs command can happen automatically when you press 'E', no?

@kripken
Owner
kripken commented Jul 16, 2012

Hmm, clearpvs does not fix this for me. Does it for you, Bobby?

It is hard to pin down the problem here. It always happens in 4 (high) but not in 3 (high_minus) I think. There are not many differences between those two,

$ diff setup_high.js setup_high_minus.js 
6,9d5
< Module.autoexec = function() {
<   BananaBread.execute('aniso 16');
< };
< 
11,14c7
<   BananaBread.execute('waterreflect 1');
<   BananaBread.execute('waterrefract 1');
<   BananaBread.execute('glare 1');
<   BananaBread.execute('maxdebris 25');
---
>   BananaBread.execute('maxdebris 12');

When loading 4, I can fix the problem by resetting the gl state, which can be done for example by /aniso 16. 16 is also the previous value, so nothing is actually changed, but all the shaders are recreated and textures re-uploaded.

@secretrobotron
Collaborator

/me tries

@secretrobotron
Collaborator

clearpvs doesn't do anything for me either. Is there a sequence of commands we should run to use it, like pvs 0, clearpvs, pvs 1 perhaps?

@kripken
Owner
kripken commented Jul 16, 2012

The only thing that seems to fix this bug for me is /aniso 16 (or aniso 1, doesn't matter which value).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment