Jump to content


Photo

Creating a light entity Def: how do we offset the light origin?


62 replies to this topic

#51 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5653 posts

Posted 26 April 2018 - 04:29 AM

@Biker: Indeed. I've just checked and light_center is not the light_origin. I never noticed that :D So creating a new entity def if you want the light origin to differ is really the only way it seems. However, I don't see the neccessity to have the same light to have different origins. That would only be inconsistent it seems, but that may just be me.

 

@Judith: The entity itself is not a light. You can see this by the entity not showing a light radius. The light comes from the attached entity (called flame). So if you want to change the texture for example you have to use set ... on. For example "set texture on flame" "lights/gathers/hammer_ornaments". You will see it works.

 

I agree that working with def_attached entities is not optimal yet. It would be nice if they would be previewable, and if one could alter settings on def_attached entities directly. But this would require code changes both in DR (at least a new gui that does something simlar like it's done in UE) and TDM (the way spawnargs are read or what gets understood by the engine might need adjustment). So it isn't impossible, but it is yet another objective on an already long list of stuff that "needs" implementation (according to what people assume needed) for a very limited amount of coders. And in this particular case we are not talking about something game-breaking, but more of a comfort function. So unless any coder consider it neccessary or anyone considering it neccessary becomes a coder, it is likely it will stay like this for a while, if not forever.


  • Bikerdude and Judith like this
FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#52 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1425 posts

Posted 26 April 2018 - 04:40 AM

I'm not 100% sure of that, but for now I believe it's more about the perception, and the way the class tree is used, and not as much a coding problem. At least based on what I did so far. I basically created two simple defs, one is the light source and it inherits the atdm:light_base:

entityDef cor_lamp01_white_source
{
    "inherit"                "atdm:light_base"
    "AIUse"                    "AIUSE_LIGHTSOURCE"
    "lightType"            "AIUSE_LIGHTTYPE_ELECTRIC"
    "extinguished"            "0"
    "light_radius"            "256 256 256"
    "_color"                "0.502 0.502 0.502"
    "texture"            "lights/do/cor_lamp01_pulse"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And the second is the model, which inherits the cor_lamp01_white_source (not func_static or anything else):

entityDef cor_lamp01_white
{
    "inherit"    "cor_lamp01_white_source"
    "model"        "models/do/cor_lamp01.ase"
    "editor_displayFolder"    "Lights/Electric"
    "light_center"        "-48 0 -32"
    "skin"                    "cor_lamp01_wht"
    "skin_lit"                "cor_lamp01_wht"
    "skin_unlit"            "cor_lamp01_unlit"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.


Edited by Judith, 26 April 2018 - 04:43 AM.


#53 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20064 posts

Posted 26 April 2018 - 04:46 AM

However, I don't see the neccessity to have the same light to have different origins.

Imho its down to a few reasons -

  • having the shader projected correctly inline with where the light would appears to be coming from - eg so faux shadows from a lantern are under the light emitting part of the lantern etc.
  • due to the way the diffuse layer on some of our textures reacts to light that very close to the surface of the brush/patch its on(its not illumintaed very well), the mapper is forced to move the center and/or the origin further away from said surface.
  • sometimes the mapper want to make sure that the radius of lights don't overlap and a quick and dorty trick is to move the origin around/away and make sure the center is in the middle of the model etc - to give the illusion to the player the area is lit correctly while at the same time not suffer from any perf issues due to overlapping lights


#54 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20064 posts

Posted 26 April 2018 - 04:47 AM

entityDef cor_lamp01_white
{
    "inherit"    "cor_lamp01_white_source"
    "model"        "models/do/cor_lamp01.ase"
    "editor_displayFolder"    "Lights/Electric"
    "light_center"        "-48 0 -32"
    "skin"                    "cor_lamp01_wht"
    "skin_lit"                "cor_lamp01_wht"
    "skin_unlit"            "cor_lamp01_unlit"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.

But, are you able to move the 'light_origin' (not light_center)around in DR..?



#55 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1425 posts

Posted 26 April 2018 - 04:58 AM

Nope, I can only move light_center, and it looks weird, as in my previous example (btw. this distinction between light_center and origin also feels confusing).


Edited by Judith, 26 April 2018 - 04:58 AM.


#56 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5653 posts

Posted 26 April 2018 - 05:00 AM

I'm not 100% sure of that, but for now I believe it's more about the perception, and the way the class tree is used, and not as much a coding problem. At least based on what I did so far. I basically created two simple defs, one is the light source and it inherits the atdm:light_base:

entityDef cor_lamp01_white_source
{
    "inherit"                "atdm:light_base"
    "AIUse"                    "AIUSE_LIGHTSOURCE"
    "lightType"            "AIUSE_LIGHTTYPE_ELECTRIC"
    "extinguished"            "0"
    "light_radius"            "256 256 256"
    "_color"                "0.502 0.502 0.502"
    "texture"            "lights/do/cor_lamp01_pulse"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And the second is the model, which inherits the cor_lamp01_white_source (not func_static or anything else):

entityDef cor_lamp01_white
{
    "inherit"    "cor_lamp01_white_source"
    "model"        "models/do/cor_lamp01.ase"
    "editor_displayFolder"    "Lights/Electric"
    "light_center"        "-48 0 -32"
    "skin"                    "cor_lamp01_wht"
    "skin_lit"                "cor_lamp01_wht"
    "skin_unlit"            "cor_lamp01_unlit"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.

In your example case you are using an electric lamp. If you check the entities shipped with DR, you'll see that most lights of that sort do not use def_attach. Def_attach is normally used for flame lights, like candles or torches. The reason is that the light has its own model, which is not the model carrying the light, but the flame itself. So you have a model that burns, like a torch or a candle, and the light entity which uses a particle as model, the actual flame.


  • Springheel likes this
FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#57 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5653 posts

Posted 26 April 2018 - 05:01 AM

BTW: extinguished doesn't make much sense on electric lights ;)


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#58 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1425 posts

Posted 26 April 2018 - 05:08 AM

Wouldn't it be easier to just offset the position of the light to match the attached particle, and still have the ability to change light properties in DR?

 

And "extinguished" "0" is actually taken from atdm:static_electric_light_lit_base, as that light source was supposed to play similar role.



#59 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5653 posts

Posted 26 April 2018 - 05:30 AM

Indeed. But it is more suppossed to be used on flame lights. Electric ones normally use start_off. Although both might work.


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#60 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5653 posts

Posted 26 April 2018 - 05:41 AM

Wouldn't it be easier to just offset the position of the light to match the attached particle, and still have the ability to change light properties in DR?

It would at least be a different approach. Easier is relative. :) Nothing prevents anyone from doing it that way when creating there own light entities.

 

EDIT: One thing that might stand in the way of doing it like this is the script object used by combined light entities (tdm_light_holder). It is possible that it needs to be altered to allow such a setup, if it doesn't already.


  • Judith likes this
FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#61 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1425 posts

Posted 26 April 2018 - 05:58 AM

IMO it would be consistent with how it's used in other engines, i.e. you want to create a light, first and foremost, right? So you go from a general light class > light with certain properties > certain light with certain model representation. From general to narrow. Not from a func_static to certain particle to certain light. The second approach forced you to create workarounds that make it all more complicated and longer.

 

Don't mean to sound rude, but IMO the whole goal of TDM was to escape from all the quirks and workarounds of Thief Deadly Shadows, not to exchange them to quirks you know and understand, because you created them yourself ;)



#62 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5653 posts

Posted 26 April 2018 - 06:09 AM


Not from a func_static to certain particle to certain light.

That isn't really the workflow. The entity is a func_static with a light entity attached to it. The latter uses a particle as a model.

 

Your approach as I understand is would be to use a light with the func_static model and attach a particle to it. In that case, all you do is to shift the light settings from the attached to the master entity. However, everything related to the particle would still be on the attached entity. So we would probably lead the same discussion, just in regards to the particle settings. And it wouldn't be consistent at all.

 

(Note that this also only relates to entities that are light holders, not lights themselves.)

 

I completely understand where you are coming from, but to make it really consistent all settings should be adjustable on the master entity, so both light and particle settings. This doesn't seem possible to me at the moment (except via the usage of set ... on), as an entity cannot have two models (the torch and the particle for example).

 

And to be honest, I don't really see set ... on as a workaround. It is exactly intented for that purpose. It would be a workaround if you would use something that is intented to do something different in the first place. This is not the case here.

 

There are several wiki articles handling attached and combined light entities, and they also cover the usage of set...on. It might not be the most elegant solution, but it does what it should. And why should there be any neccessity to be consistent with other engines? What is the issue on using the editor and engine the way it is intented to be used?


  • Springheel and Judith like this
FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#63 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1425 posts

Posted 26 April 2018 - 06:22 AM

There is no need to be compatible with other engines just as a principle, but you can see that they build the structure better, and prioritse functions according to users' needs. With light entities, you need to be able to change light properies often, that's a priority. Particles can be attached e.g. to a helper, or just in relation to a static model, and tweaked in particle editor, and that's it, for most cases. The main goal is always speed and ease of use. As you know, mapping is already long and complicated process, so everything that speeds it up, even just a little, is invaluable. That goes for both using the editor/engine and amount of things or parameters to keep in mind while mapping.





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users