GoW PyPRP 1.6.0 Beta 2 released

[boblishman]

Christian ...I have noticed one (small) thing with 1.6 that never seemed to happen before...

If I use a texture and use the "Clip" option (to stop it repeating on a decal) when I go in game there are some strange "artifacts" from certain camera angles at right angles to object centre of the mesh ... like a series of lines that run to the edge of the e... that I can only cure by reducing the size of the decal so that there is no repeat on the decal in Blender ... it's quite odd... .

[Christian Walther]

I don't completely follow your explanation (can you show a screenshot?), but you may be seeing z-fighting, i.e. two coincident or very close surfaces (decal and background in your case) compete for who gets to be drawn in front of the other, and due to rounding errors, on some pixels one wins and on some the other, usually in a flickering pattern depending on the camera angle. I don't know what the standard Plasma way of avoiding that is, does it have a polygon offset setting or something like that? I don't recall any specific change in 1.6 affecting this, but I may be wrong. Do the artifacts disappear when you move the decal away from the background by 0.1 units or so?

[dendwaler]

Thx for the fix Christian!

I have updated the PyPRP with your new objclass and my age exported like a dream!
No bounds problems at all!
Thx for your hard work and quick solution.

Martin

[boblishman]

Christian ... this is the kind of thing I mean ... here you can see two of the cross's "arms" ... they only appear during certain camera angles ... and when the image you are using has a repeat on the mesh in Blender but you "disable" that repeat using the "Clip" button ...

artifacts.jpg (23.18 KiB) Viewed 3193 times

[Christian Walther]

OK. This is not z-fighting. Here's my guess as to what's going on here:

The "Clip" button maps to a slightly different feature in Plasma than in Blender. It does not set the texture to transparent outside of the main rectangle as in Blender, rather it stretches the outermost pixels of the texture to the entirety of the surface outside of the rectangle, as in Blender the "ClampX" and "ClampY" buttons in the "Real-Time Properties" panel in the UV/Image Editor window do for the textured real-time view.

So, these arms happen where the circle in your texture touches the edge of the texture rectangle, so that the outermost pixels that are stretched out are not completely transparent. The reason why it only appears under certain angles is mipmapping: when you are close to the surface and looking at it approximately perpendicularly, a low mimpap level (big texture image) is used, where the edge pixels are transparent. From farther away or under a more shallow angle, a higher mipmap level is used, i.e. a scaled down version of the original image, and in that smaller image the circle extends into the edge pixels (which take up a greater proportion of the image).

The way to fix this, therefore, is to make the circle on the texture a bit smaller so that there is a wider border of complete transparency around it. Ideally, you'd make sure that in every mimpap level, down to 1x1, the outermost pixels are completely transparent, but since PyPRP does the mipmap scaling for you, you have no control over that.

Unless you can demonstrate that this happens in 1.6 and not in 1.5, I'd say that this is not a bug, but working as intended. The inability to avoid the problem entirely though (if I'm guessing right and it exists) seems a valid issue and could perhaps be solved by heuristically using a different mipmap scaling algorithm for such textures.

[boblishman]

Thanks for the explanation Christian ... (I knew it was not z fighting)

... without rolling back to 1..5 I have no way of testing this and saying that it is only happening in 1.6.
However, I have been using textures with clipping since the GoW plugin started way back when ... and I have never had it happen until now ...

As I think I said, I cured my textures (like the one above) by actually reducing the size of the plane so that there is almost no repeat of the texture ...

[Christian Walther]

... without rolling back to 1..5 I have no way of testing this and saying that it is only happening in 1.6.

Well, obviously. But is there any difficulty with rolling back to 1.5 (assuming you want to)?

[Christian Walther]

While testing this, I found some unrelated issues with bounds export - sphere bounds cause an error (some things look half-implemented there), and something seems to be wrong with the transform of box bounds. Will investigate.

I was mistaken about the box bounds (they work fine), and seeing as I still haven't gotten around to writing and testing a proper solution for the sphere bounds problem, I'm going to save that for the next release. I don't want to break anything as close to the announced release date.

I'm working on packaging up beta 2 now and should get it out later today, assuming that I get hold of Hoikas to put it on the server.

Edit: Beta 2 is available from the first post now.

[andylegate]

Just a suggestion, as it's been suggested before, but you need to get people's attention a bit better on how 1.6 installs different than the previous versions of pyprp. I suggest editing your very first post, and use large, bold sentence at the beginning that simply says:

PyPRP 1.6 Installs differently than previous versions of PyPRP. READ the install section on the wiki.

Most people will be like me: Ah! New version! Cool! :download: now just unzip the files and dump them in my script folder.....and it don't work...huh??? OH! READ the instructions! Why would I do that???

Also, make sure everyone knows that if they install the new version of Blender, they will have to make sure they install Python 2.6.2 (Blender got upset with me about that).

And, when I tried to export the first time, I immediatly got an error message about PyYAML, I had to re-download and reinstall it.

EDIT: Scratch that, I had to reinstall PIL too, so pretty much to use this version of PyPRP, I had to reinstall (redownload and reinstall actually) EVERYTHING, kk, good to know.

But now I am getting a different error when I go to export. I'm using Serene as it successfully exported just fine before with previous versions of PyPRP. Here's the error I'm gettin:

Code: Select all


[Sound Emitter ambsound1]
 [Coordinate Interface ambsound1]
Traceback (most recent call last):
  File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\prp_Export.
py", line 169, in open_file
    export_age(agename,basepath,selection,merge)
  File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\prp_Export.
py", line 83, in export_age
    page.export_all(selection)
  File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\PyPRP\prp_R
esManager.py", line 501, in export_all
    plAudioInterface.Export(self,obj,scnobj,name,SceneNodeRef,softVolumeParser)
  File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\PyPRP\prp_S
ndClasses.py", line 117, in _Export
    win32snd.data.exportObj(obj, softVolumeParser) #We need to pass the parser
  File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\PyPRP\prp_S
ndClasses.py", line 847, in exportObj
    plWin32Sound.exportObj(self, obj, softVolumeParser,RndSndName)
  File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\PyPRP\prp_S
ndClasses.py", line 742, in exportObj
    raise ValueError, "Cannot locate any sound named \"%s\"" % sname
ValueError: Cannot locate any sound named "srnamb1"


Off to look at this thread and see if anyone else encountered this.

Edit: DUUUUHHH....I is an Age Builder! Duuuuuuuhhh....

Forgot to make sure the sounds where in the sfx folder. Been so long, I had forgotten I made a clean install of Uru.......oopsy. Okay,.....BUT.....and I have to use a few choice swear words here. Now I've got to go in and change ALL of my scripting for visregions now.....sigh.

[andylegate]

kk, I've noticed another difference with 1.6.0 with the visregions:

Prior to your new release, pyprp didn't care what page the visregion was on to affect the objects for it. NOW it does. The visregion that affects Object X, must be on the same page_num as Object X, else it won't work correctly.

I've changed the Vis Regions tutorial over at the GoMa Age Creation Tutorials section. I looked, but I'm not finding a Vis Regions tutorial on the GoW's Wiki, only the Soft Volumes explination (which needs to be edited now).