[blizzart]

Mblackwell, on 23 February 2013 - 06:12 PM, said:

Wasn't it 0-255?

TerminX, on 23 February 2013 - 06:43 PM, said:

Yes, but a few of the higher values are reserved.

Thank you both Mblackwell and TerminX,
that are enough for sure. I just wanted to know, if I can have more than 64 palettes.


But another question: can I define a normal map to a texture only once or can I have a normal map for every pal I use?

[Fox]

Just a small request, is it possible to return the badguy check from the source code in CON? Thanks.

[Mblackwell]

blizzart, on 24 February 2013 - 12:40 AM, said:

Thank you both Mblackwell and TerminX,
that are enough for sure. I just wanted to know, if I can have more than 64 palettes.


But another question: can I define a normal map to a texture only once or can I have a normal map for every pal I use?

Once.

[blizzart]

Mblackwell, on 24 February 2013 - 06:02 AM, said:

Once.

That´s sad. This would have give us the opportunity to use skins with many differences like beards, hair or no hair and much more.

Anyway, it´s not that big problem, so we will stay to different skin colors and clothes.

[Mark]

Use the skins with beard and hats like regular. When making the alt pal skins, leave the beard or hat area transparent. It should work fine when applied to the model.

[Mblackwell]

But the normal would still affect it (I think... ?). But since it's an attached prop you could probably get away with a separate model that follows the animations of your actor and just lock it to the actor's position.

[Micky C]

Is there any way of having both a fogpal and a regular pal on a sector? Maybe some way through con code? Or perhaps in the future with the new map format?

[Kyanos]

The Big Cheese, on 01 March 2013 - 03:21 AM, said:

Is there any way of having both a fogpal and a regular pal on a sector? Maybe some way through con code? Or perhaps in the future with the new map format?

What are you trying to do here? I bet that whatever the results are you're looking for, they will be possible using some con code.

[Micky C]

Well for example have an entire area blue (using pal 1 everywhere), however have a non-black fogpal.

I realized since making that post that I can get an effect very similar to what I wanted by using pal for fogpal, and the con effect to create an underwater global pal (as long as you've hooked up highpalookup to the underwater pals )
So in the mean time it's all good, however if I or anyone else in the wants to use other colours then they're in trouble.

[Kyanos]

There are more game palettes than just water, and more pals to choose from than you can shake a stick at. I'm curious now what might happen if I define a fogpal and highpal to the same pal number, will both be applied, or one or the other?

Hmmm... possibilities here, too much to talk about, no time, here's a pic. Everything is pal 26 a gray fogpal, I also defined it as a highpallookup, the pal 4 all black... 8-bit art stays normal while hightiles and models change.

[Micky C]

Hmm that's a good solution, defining both, however it would need to work for 8 bit art as well, not just high res textures and models. Don't worry about it though, I'm satisfied with my original solution (still provided that you've hooked up the underwater highpal, I haven't updated lately).

[Steveeeie]

I'm not sure if this has been mentioned before, or if its something other have noticed.

Models with alpha maps in the hrp have a bit of a problem.

If polys have an alpha map applied to them, the become transparent(expected) but polys sitting behind also become transparent, is there a way around this?

I will follow this up with a screen shortly.

[Micky C]

We know what you're talking about. It can be fixed eventually, but there are higher priorities.

[Steveeeie]

The Big Cheese, on 02 March 2013 - 04:41 AM, said:

We know what you're talking about. It can be fixed eventually, but there are higher priorities.

Thanks

Do you know if there is support for two sided textures ? I'm currently getting around it by flipping duplicated polys atm, but its a bit of a waste of resources
.

[Micky C]

Steveeeie, on 02 March 2013 - 04:46 AM, said:

Thanks

Do you know if there is support for two sided textures ? I'm currently getting around it by flipping duplicated polys atm, but its a bit of a waste of resources
.

I'm not a dev, just a mapper who spends a shameful amount of time on these forums, and utters jargon that I occasionally read about here without understanding
I'm on my phone right now haha.
But IIRC I don't think there is at the moment, but it will probably be added in the future.

Just to be on the safe side, wait and see what Plagman has to say about it.

[Mark]

I'm not up on the tech speak either, but if it means anything I think "backface culling" might be enabled in the engine. Would that be your problem?

Other will know for sure.

[Gambini]

Steveeeie, on 02 March 2013 - 04:46 AM, said:

Thanks

Do you know if there is support for two sided textures ? I'm currently getting around it by flipping duplicated polys atm, but its a bit of a waste of resources
.

In the meantime, duplicating the desired polygons and inverting their normal to simulate "nocull" is technically less expensive (at least in other engines for which I do models from time to time). And you dont need all polys to be double sided anyway.

[Plagman]

Yeah, that's the way to go. The problem with translucency is a general thing that I need to tackle, but as a general rule of thumb make sure translucent parts of your model are in their own surface, and if there is specific disjoint parts make sure they're on separate surfaces as well, so that the engine can sort them roughly.

[Kyanos]

Plagman, on 02 March 2013 - 09:30 AM, said:

Yeah, that's the way to go. The problem with translucency is a general thing that I need to tackle, but as a general rule of thumb make sure translucent parts of your model are in their own surface, and if there is specific disjoint parts make sure they're on separate surfaces as well, so that the engine can sort them roughly.

It's nice to have rules like this! Any other tidbits you'd like to share. I have many models with transparency and have learned parts of this rule the hard way. However it's news to me to that it's a well known general rule, it's not always easy learning these quirks.

[Plagman]

It's not really a rule for today, though it can help some. What I meant if that if you did that, it would make it easier for me to improve the situation later when I get to it.

What the engine does now is determine which models to draw, then go through them in a rough closer-first order and draw all their surfaces, in order. That means that if the part of your model that's fully opaque ends up behind the part that's translucent from the angle you're looking at it but everything is in surface 0, your translucent stuff might not be drawn in the right order and you might not see through it. If you move the translucent part to surface 1, you're guaranteed that it's at least going to be drawn after all the opaque parts of the same model.

Now, what I want to do eventually is have a "translucent" DEF token that tells the engine "this surface is translucent", because it would be a huge pain in the ass to try to examine the models at runtime to figure out which parts are translucent or not. This way the engine could draw all the surfaces of all the models that are opaque just fine, then walk through the translucent surfaces only and try to figure out how to alleviate any artifacts (by trying to sort them, or any other approximation that would yield better results than today). This way even if the method to make it look OK is expensive, it would only apply to a small portion of the scene.

Intersecting translucent planes are never really going to work right, however. It's not wonder than modern games avoid translucency like the plague and always use alpha-testing for world stuff. The only translucent stuff you see are particles, which are easy to sort since they're conveniently aligned.. Even things like glass panes are generally rough approximations, like additive blending.

[Mblackwell]

Couldn't you have users flag them so they are both drawn fully and blended?

[Plagman]

Which part are you referring to exactly? You can't render intersecting translucent planes without breaking them up into more polygons and carefully sorting them, which is very expensive.

[Mblackwell]

That part. I'm saying skip proper sorting and blend them if a flag is set by the modder. This would look terrible if any part wasn't alpha, and could produce visual artifacts, but for many instances it would be as good as anything.

[MusicallyInspired]

MusicallyInspired, on 09 February 2013 - 08:38 PM, said:

Got a problem with polymer on my laptop. My laptop is a decent build with a NVidia GeForce GT 550M 2GB video device. Polymer works fine and smoothly except for spotlights. In Mapster and ingame the spotlights don't show up at all. If I do 'restartvid' in the console the spotlight will appear for a split-second before disappearing again (also, I've noticed that it does not cast a shadow). I'm not sure if this was ever a problem before or not as I don't remember if I ever saw an ingame spotlight on my laptop or not. I guess I just assumed it would work. I'm already running the latest driver so that's not the problem. Any suggestions? I've tried the latest snapshot as well as the 64-bit build that was posted a little while back. No change. I'm not sure why it's not working as it's a decent NVidia card and NVidia is supposed to the best compatible device for polymer, right?

The eduke32.log file displays these lines of messages every time I typed in 'restartvid' if it means anything:

Can I bump this one more time? Also, I notice when playing e1l1 the spotlight in the street flickers on and off, and still no shadows.

[Gambini]

Are you sure you dont have either an autoexec.cfg or something in your eduke32.cfg disabling those?

I say, because, if you ever run a command like r_pr_lighting it will be embedded into your cfg forever.

[The Commander]

MusicallyInspired, on 02 March 2013 - 07:50 PM, said:

Can I bump this one more time? Also, I notice when playing e1l1 the spotlight in the street flickers on and off, and still no shadows.

A full log file please would help, and do what Gambini said and remove ANY 'CFG' files.

[MusicallyInspired]

There are no CFG files except for eduke32.cfg. Delete that? I apologize about the log not showing up. I inputted a portion of it in the original post, but it didn't show up in the quote. Here's the log. It seems the output from the previous log contents isn't the same this time around. Don't know what's going on.

EDIT: Ah, I just noticed that it's using my intel graphics chip instead of the NVidia one. That might be it...

Attached File(s)

•  eduke32.log (138.85K)
  Number of downloads: 453

[The Commander]

Yes delete all CFG's
They will be regenerated next time you launch.

[The Commander]

Well there is your problem...

Quote

Setting video mode 1920x1080 (32-bit fullscreen)
OpenGL Information:
Version: 3.1.0 - Build 9.17.10.2867
Vendor: Intel
Renderer: Intel® HD Graphics 3000

Either you haven't installed your NVidia GeForce GT 550M correctly or you have really messed something else up, but it's still using your Intel chip as the video driver.
Please make sure you have the latest Nvidia drivers.

Also using the latest eduke32 wouldn't go a miss either. (Your version is 3 months old)
http://dukeworld.duk...e32_current.zip

[MusicallyInspired]

Yeah, I just noticed that. It looks like the Intel graphics were set to global default for everything on my laptop and wasn't using the NVidia at all. A quick switched solved the issue. My mistake.