Boothand

Hmm yeah normal maps tend to make everything look shiny, I think. Not used any speculars here yet. Any way around that? I'll have to play around with the smoothing of it tomorrow probably, the shadeangle is currently at 20. Just got home on easter holidays a few hours ago, need some time to set it up on my laptop. Would gladly accept a brand new rend2 if anyone has one

Ah. I just followed what the old Spacemonkey tutorial said about naming extra parts (also kyle's eyes_mouth had done the same)

It seemed I had to rename eyes_teeth to head_eyes_teeth, and link it to the head. Then it compiled! Now I just need to redo the weighting after all, because it looks like it comes from the sewers...

Finally pulled myself together and did what remained to be done on my horse model, but some detours made me get out of the *flow* that I'm used to, and now after very much black magic tinkering with the Skin modifier in 3ds max, it still doesn't work. Here's the error it gives. @@Psyk0Sith, any ideas? Can you open Max 2011 files? https://dl.dropboxusercontent.com/u/58757568/Horseton8_UVEXP.max https://dl.dropboxusercontent.com/u/58757568/Horseton8_UVEXP2.max I have two max files, one before I experimented with something. In this version it lets me export in the position it's in when you open the file, but if you highlight either the skin modifier or the Editable poly modifier, it snaps out of place, when you exit the highlighting, compared to the skeleton, and I have to do that for all the limbs, and move it and align it again. But that error. The second file, what I did was resetting every pivot point to 0,0,0 and moving them manually "in place" on eye-measure in Element mode (thus moving the mesh, not the pivot point). In the first file, the eyes_teeth model has a very different pivot point, around where the skeleton is, the rest of the model parts' pivot points are far out. That's what led me to using the same pivot point and aligning them after, but this is apparently not what's causing the error. (Using autolinker for the hierarchy)

I would really love a basketball grenade toss game Enjoyed it in the skatepark.

Tried the map out for a little bit now. I was really positively surprised by this map. It's easily one of those classic memorable JK2 maps! I found much joy in finding undiscovered areas or details again and again, even though it really feels like one concise and solid map. Very entertaining, very nice brushwork, cool atmosphere and nice balance of features vs staticness, so far. Good FPS, no visual problems (it did require me to go from 64 to 128 com_hunkmegs by the way). Looking forward to the release. Good work There was one missing texture, the brush that curves around the poles in the dojo. Also, the pine trees could be collision-clipped more precisely I think!

So blocking an incoming swing is basically done by swinging your own saber at it correctly (if you're lucky)?

Since this thread has to do with knowledge of the game, I'll give it a try here. I've asked on several occasion people in-game but no one seems to answer or they don't seem to know what I'm talking about. Saber blocking. Blocking a swing with your saber. How does it work in JA? Is range all that matters? Can you choose to block any attack? Is chance involved in the calculations? Can blocking be an advantage in JA (I see that you get stunned)? I notice when testing it myself that probably... 8/10 times I just mash through the saber as if it wasn't there, and opposite. Could this be included more or less extensively in the guide?

I tried but didn't see any effect of the normal map so far. Not quite sure of the best way to shader this, since there's so much transparency too. I'm excited to see it working though, if anyone's up for trying as well Update: Both deformVertexes and blendFunc X seems to break it for me. I am able to have a normal map on it before it's deforming and before it's transparent - that is before it looks like water at all.

Just made a stone! 3 different lighting conditions (r_forcesun 2 and last one without forcesun): https://dl.dropboxusercontent.com/u/58757568/lyingstone1.jpg https://dl.dropboxusercontent.com/u/58757568/lyingstone2.jpg https://dl.dropboxusercontent.com/u/58757568/lyingstone3.jpg

I never intended to use that for more than debugging

Yeah, it's not a priority now of course. I just feel it adds so much potential with atmosphere. So maybe eventually. Well, you can both have animating skyboxes, and you can add other moving entities such as a sprite with a bright sun shader, which I think would look good. But I don't know how you would instruct the renderer's sun to move with it. Maybe by making a new entity for rend2, such as has been done for cubemaps.

I have an important question now. Is there gonna be any use of the sun's dynamics? It's already proven that the engine handles lighting and shading when light moves around, and it even displays normal maps correctly as the light source is moving (read: r_forcesun 2). And this is already looking so impressive - is there no way to add possibilities for a moving sun (at any speed), clouds making variations in light conditions etc? It just seems like it's all already there, but the way I've understood it, it's not the aim for the renderer. What's the situation/thoughts on that?

Minlight works great for making the shading look more natural! It does also help lighten up my trees, but my bushes remain very much black (unless you squeeze your face into them, but even then). It doesn't seem possible to set minlight per entity. Flipping the green channel with the shader seemed to do the trick (for some reason! I thought it would just reverse the problem to the back, but it's all good now..) PS. I take back what I said about the normal map not responding to the moving sun... it does.

In my case, the backside of the model's normal map looked correct, but the front side looked inverted. Then another place there was accidentally a normal map (on the computer) it looked correct. But it was all the same normal map. I'll check out the minlight stuff Intensity didn't have much effect on the shadows at least, not sure if it worked at all.

I made a little video showing some rend2 (and possibly some bugs). Forgive my babbling at times. I have a cold, and don't even sound like myself Also I kind of went on a bit longer than needed, but have a look. Things that happen: -Black planes. -Random inverted normal map (?). -White saber marks. http://www.twitch.tv/journeytobootland/b/516155702

https://www.youtube.com/watch?v=JitOUDxGVig It actually made me speak "Wow" out loud, trying this in-game. All the problems caused by weird shading in the lightmap are now gone. The rotating box I was testing with receives light as it should when it rotates, and darkens on the sides not facing the sun. I really recommend to anyone trying _rshadows 0/_cshadows 0 on all entities in your map and testing it out with rend2. It's not the same as skipping the light compile of course, it maintains the good vibe and color but makes it compatible with rend2's sun. Great. On the other side, this obviously reduces compatibility with vanilla. But then again, rend2 performs 3x better on my map than vanilla seems to do. It wouldn't be much compatible in any case One hitch for now, using _rs 0 on my models, planes seem to be completely black. I only suppose that's what's causing it, but that's the only visual issue so far. Any ideas?

Will anything else eventually prevent the lightmap from competing with rend2's light?

If r_sunlightmode 2 is eventually going to disable the lightmap, how would it differ from what you see when not compiling the light in q3map2, but running rend2? Tried that just for curiosity, but didn't look good of course.

Same problem in Modview? Could it be something wrong with the model? Flipped faces on the other side?

Still have this issue. Anyway, would any of you be interested in sort of co-crafting this map with rend2 features? Will rend2 coders use it to test stuff? The purpose of the thread was to more or less make an ultimate rend2 testing map, for mappers/coders/whoever

Haha ok. Is it a long way until dynamic lights work?

Togglable lights are pretty interesting at the moment

Actually I have a functional 8 sided water brush in my map, so that shouldn't be a limitation.