[Supertanker]

Okay, I hacked some extra stuff into the exporter to make it pay attention to mesh name for exporting (now if I say 1_body, 2_plant...etc, it'll go in order so I can export the hair last :>). Here's my remaining problems:

1. Eyes and teeth are see-through (didn't notice; should be easy to fix)
2. Hair, even though it no longer allows the player to see through the body, allows the player to see through the hair itself because I doubled the mesh with the normals inverted to make it two sided. Is there a better way to do this, or should I just eventually make a low poly hair mesh without transparency?
3. The normal map has very visible seams (though not sparkly/transparent ones like before), but it (for the most part) looks great. The main area of distortion is around the breasts because I modified the geometry to make them appear more natural. I just need to tweak the highpoly mesh before baking. I'm not sure how to really fix these lines. Those are the seams in the UV mesh. I don't have a Windows machine to try xNormal at the moment, but I may this weekend.

NSFW pictures (hair problem and line problem visible):

http://supertanker.m...t/603_prob1.jpg
http://supertanker.m...t/603_prob2.jpg
http://supertanker.m...t/603_prob3.jpg

If I could fix those three things...well, I'm happy with it. :>

[Micky C]

 Micky C, on 18 January 2012 - 05:48 PM, said:

I'm in the mood for messing around in mapster but I don't have the energy to work on a map. What would people say if I decided to do polymer lights for episode 4? The thing is it already has lights by devestator, they're not all that bad, but they don't match up to the thoroughness of episodes 2 and 3 either.

Like Homer Simpson always says: silence means yes.

e4l2, Duke Burger
I left most of the outdoor lights the same as devestator's, but added a few anyway, and basically redid all the interior lights. Although I'm not sure if this should replace the previous lights just yet, I used an awful lot of spotlights a la Project Zero, but not quite so bad, still the framerate isn't that hot. I was thinking long term when I did this.

Attached File(s)

•  E4L2.zip (4.74K)
  Number of downloads: 253

[LeoD]

 Micky C, on 18 January 2012 - 08:41 PM, said:

Like Homer Simpson always says: silence means yes.

[Micky C]

Babe Land done.

Attached File(s)

•  E4L4.zip (4.87K)
  Number of downloads: 243

[Supertanker]

Minor update: fixed the hair, fixed the eyes. The main issue now is just the normal map, and I think I'll release it without the normal map for now until I figure out what's going on there. So 603 should be ready in the next few days.

In regards to the Z-axis problem: Hendricks266 added a yoffset parameter to the .def parser that allows for an "absolute" change in z for those tiles that have peculiar offsets like #0603. It's recommended that zadd be used instead for other models since it is sufficient for almost all cases. For more info, see http://dukeworld.duk...4/ChangeLog.txt

You will need at least eduke32 revision 2264 to use the model properly.

So, once this is released, you will not need maphacks that adjust the height of the model--it will work out of the box for both stock maps and usermaps. (Although, of course, you may need one to randomize rotation :>).

[NightFright]

Just remembered something: If you are using latest HRP, you have to be careful since the maphacks are inside the HRP file. Which means: These hacks actually are for the bugged slimebabe model. If you got it working with the new one, the hacks will most likely screw it. So maybe remove maphacks first before you are testing your stuff ingame.

[LeoD]

 NightFright, on 23 January 2012 - 08:47 AM, said:

If you got it working with the new one, the hacks will most likely screw it. So maybe remove maphacks first before you are testing your stuff ingame.

...or create an empty corresponding E*L*.mhk in your game directory.

Btw., I just noticed that maphacks.txt is not part of the repository...on purpose?

Another question - if I play a user map, say sand.map, would a corresponding sand.mhk be loaded automatically or does this only work for the original levels aka E*L*?

[Master Fibbles]

 NightFright, on 23 January 2012 - 08:47 AM, said:

Just remembered something: If you are using latest HRP, you have to be careful since the maphacks are inside the HRP file. Which means: These hacks actually are for the bugged slimebabe model. If you got it working with the new one, the hacks will most likely screw it. So maybe remove maphacks first before you are testing your stuff ingame.

If he is anything like many modelers, he has a map that has the models he is working on in a room with lights so he can see the model as it is with lighting etc.

[Supertanker]

 NightFright, on 23 January 2012 - 08:47 AM, said:

Just remembered something: If you are using latest HRP, you have to be careful since the maphacks are inside the HRP file. Which means: These hacks actually are for the bugged slimebabe model. If you got it working with the new one, the hacks will most likely screw it. So maybe remove maphacks first before you are testing your stuff ingame.

I don't play with maphacks--but thanks for reminding me :>

 Mr.Flibble, on 23 January 2012 - 01:13 PM, said:

If he is anything like many modelers, he has a map that has the models he is working on in a room with lights so he can see the model as it is with lighting etc.

Yeah; I threw together a quick little map (called newboard.map, how strange!) for testing. Easy enough, after all, my main talent is mapping. Pretty sure there's no newboard.mhk in my eduke directories.

I guess I should upload it soon until plagman fixes my seam issue too. :>

[Plagman]

I think about it daily if that makes you feel any better...

[Tea Monster]

Supertanker - Which version of Blender are you using? They fixed some seam issues with baking in one of the latest versions.

[Supertanker]

I'm running trunk from just a few days ago. It's not so much the seams in the UV map as the exporter (apparently) making a "hard" seam in the mesh by duplicating verticies, which messes with the way eduke does normal maps. Or something. I painted over the seams in the normal map by hand in Texture Paint mode but they still showed up in game, so, frustrated.

[Kyanos]

 Supertanker, on 24 January 2012 - 08:46 AM, said:

It's not so much the seams in the UV map as the exporter (apparently) making a "hard" seam in the mesh by duplicating verticies, which messes with the way eduke does normal maps. Or something.

Ya, that's not so much the exporter as it is a rule of the md3 format. NO FACES CAN SHARE VERTS.Iwaswrong

Added: We could pass around a petition for, say, MD5 support. JK. Plagman

[Hendricks266]

 Drek, on 24 January 2012 - 03:15 PM, said:

Added: We could pass around a petition for, say, MD5 support. JK. Plagman

This has been discussed. I'm too lazy to find the quote (it's in a dialogue about voxels) but MD5 would not be a useful addition since it uses skeletal animation and Polymer was not written with this in mind, meaning the animation would have to be "rerendered" for each frame if you understand my point.

[Kyanos]

Well that was my biggest pro for using MD5, it would save some file size and be easier to edit animations down the road. Oh well, I for one like MD3s

[Plagman]

When we have the new animation suppot and support for skeletons all the way into the engine, I'll add md5mesh support for sure.

MD3 faces can share vertices just fine, but not if they don't have the same UV coords or normals, which forces the exporter to duplicate verts and split the mesh across UV seams and smoothing groups. Keep in mind that if the exporter wasn't doing that, EDuke32 would have to do it when loading the model anyway since that's also how GPUs work.

[Tea Monster]

If it's the UV's that are causing you problems, then you can copy the mesh to another layer, re-uv-map it so that you don't have to have any overlap, then you can cross-bake the overlapping mesh to the non-overlapping mesh and that way you don't have to spend hours in Photoshop trying to re-jig everything.

[Supertanker]

Nah, it's not the UVs. It's the physical structure of the mesh and the way the exporter handles UV seams unfortunately...anyway, I'll try to push it out tomorrow.

[Supertanker]

NSFW: hanging babe model

Requires recent eduke32 with the yoffset token. http://dukeworld.duk.../20120116-2264/ or later should do. It's about as done as I'm going to get it.

[Master Fibbles]

The model and animation is of good quality. I wonder if modelling the teeth/mouth is even necessary but it isn't like a lot of details could be added on the model itself besides. I like the style of this model more than the previous version(s) of the babes. Do you plan on continuing and completing at least the rest of the slimed babes?
I think the skin could benefit from more details. I see from the defs that you had a normal map planned but didn't include/finish it?


Great job on this!

[Supertanker]

I will probably work on the other babes (except possible for the impaled one) as free time permits now that my job is back in full swing. I have a good start on the standing slime babe.

As for the normal map, I am waiting for a few issues to be solved. It looked very nice but there was that big fat seam that I couldn't get rid of even after manually smoothing the seams in the normal map with blender's texture paint tool--it seems to be something in eduke32 giving issues.

Thanks!

[Hendricks266]

polymer_hrp r288:

Quote

Revise #336-338 (water texture) from the original JPEGs to remove artifacts while maintaining the integrity of the texture.
I originally did this in 2009 but the process caused subtle differences in the texture, and it did not solve the issue of artifacts in the very dark shades between the highlights. This time I used two Selective Gaussian Blur passes in GIMP, one on highlights and one on the dark gaps, with settings so that it blended away artifacts without causing any noticeable change to the artwork that I could detect.

[Helixhorned]

Alright, so I'm doing simplifying transformations on the dynamicremap code, and when checking my changes before the commit, discover that the whole system in its current state is one big stinking no-op, and has been since a small, but significant typo/inattention committed by Hunter_rus with r1031. This means that this system has not been working for more than three years without anybody really complaining. What I'll probably do is keep the code, but conditionally compile it out until somebody provides a convincing use case.

The would-be patch is attached, for anyone interested. Here are some technical notes to make sense of it:

Spoiler

• struct dynitem list[].val was never written, and was always initialized with its 'vstat' (renamed to 'staticval'), which is why I removed it
  
• G_InitDynamicTiles() runs after all G_ProcessDynamicTileMapping() invocations, which are done from 'define' token processing during CON compilation

edit: What's also weird is that its origins are totally unclear to me. The Wiki claims it to exist since EDuke 1.2.9, but apparently it has been removed in EDuke 2.1 (source from RTCM).
edit2: oops, this was supposed to be in the Polymer/EDuke32 thread.

Attached File(s)

•  dynamictileremap_noop.diff.txt (129.14K)
  Number of downloads: 287

[Danukem]

That's pretty funny. I can honestly say that I have never tried using it myself.

[Fox]

 Helixhorned, on 28 January 2012 - 02:34 AM, said:

This means that this system has not been working for more than three years without anybody really complaining.

I complained... and if I remember correctly it was DeeperThought who wisely told me to forget about it and so I did.

[Hendricks266]

I used dynamicremap in H266MOD.

It needs to be kept in general. It's a good feature.

[NightFright]

I am preparing a small first update pack for current HRP 5.1. Right now, not much is included, just two new textures and the slightly improved water by Hendricks. If you got the new babe model fully done though, it would make much more sense to release something. If you got the flipped version working without requiring maphacks, be sure to warn me first so I can remove the lines from all maphacks where it shows up.

[Supertanker]

 NightFright, on 31 January 2012 - 01:36 AM, said:

I am preparing a small first update pack for current HRP 5.1. Right now, not much is included, just two new textures and the slightly improved water by Hendricks. If you got the new babe model fully done though, it would make much more sense to release something. If you got the flipped version working without requiring maphacks, be sure to warn me first so I can remove the lines from all maphacks where it shows up.

Oh, it's done--completely. I'm not going to fiddle with it unless Plagman happens to find time to tinker with the normal smoothing code. By all means, please add it to the pack and remove any lines regarding height adjustments. Remember you need a newer Eduke32 to play it though--the fix is an adjustment in how eduke32 handles models with a large yoffset, of which 603 is the largest offender.

[NightFright]

OK then, but wasn't it still missing normalmaps (for the body skin - but well, the other babes don't have one either right now)?
And a glowmap for the eyes might also be nice (but I can add that by myself, I think).

*EDIT*
New slimebabe added to SVN (build 289).
I have modified it a bit by adding (much) more sophisticated nipples (before, it looked more like a robot xD) and red glow for the eyes. Also adjusted the maphacks so it looks right in E3L1, E3L3 and E3L6. I will work on a new XXX Pack skin now, I guess.

[Supertanker]

Normals maps are not coming until the shading issue is fixed And yeah, you can probably do the glowmaps better!