Jump to content


Photo

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


62 replies to this topic

#1 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 18 April 2018 - 11:27 AM

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

@Biker: What issues? I didn't get it it seems

Sorry I probably wasn't clear enough with my initial post.

 

The attached snippet shows a typical electric light source, and you can see the light origin is the exact same location as the origin of the model.

 

Capture.JPG Capture1.JPG

 

The issue's are -

  • if I dont use def_attatch I can't change or move the light_origin, which means for example a shader with a pattern (tdm_lantern) with directly under the origin of the light, not the light_center which idealy where you would want it.
  • So then a mapper would then use def_attach so he/she could change the location of the light_origin eg
    "def_attach"                         "light_candleflame_unlit"
    "pos_attach"                         "flame"             // At the attach point called "flame"...
    "attach_pos_name_1"          "flame"             // ... which is defined here.
    "name_attach"                      "flame"            // Give it a name to pass along spawnargs
    "attach_pos_origin_1"      "0 0 10"          // Offset the origin of the light/flame X number of units in the Z direction 
    "light_center"                        "0 0 20"          // Offset the center of thelight/flame X number of units units in the Z direction
    "light_redius"                        "130 130 130"          // size of the light radius
    "texture"                                "lights/biground_candleflicker_shadow"  //shader for the light souce
    "_color"                                 "0.80 0.6 0.23"    //colour of the light souce

And now I have just realised what i was doing wrong, which was causing TDM to ignore my "light_radius" in-game. I was using "light_origin" instead of "attached_pos_origin" and this was because I thought it would be the same nomenclature as 'light_center' and 'light radius'.

 

The issue with def_attach is that the mapper can't then change the origin in DR, its has to be done in the .DEF file for that entity. Or they can force change the setting in DR using the following args -

// Flame

"set light_radius on flame" "100 100 100"
"set color on flame"
"set s_volume on flame" "-20"
"set attach_pos_origin on flame" "0 0 0"
"set _color on flame" "0 0 0"

// light

"set light_radius on light" "100 100 100"
"set color on light"
"set s_volume on light" "-20"
"set attach_pos_origin on light" "0 0 0"
"set _color on light" "0 0 0"

As some have mentioned in this thread, it would be nice to be able to change the above setting in DR using normal methods, not args. I guess the only way yo do this is for DR to create new definitions? like it does when you modify or create new particles?


Edited by Bikerdude, 25 April 2018 - 04:22 AM.


#2 Goldwell

Goldwell

    Team Member

  • Active Developer
  • PipPipPipPip
  • 2407 posts

Posted 18 April 2018 - 11:53 AM

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

 

If the light entity is spawned in you could set the origin of the attachment. So for example for the entity "atdm:sconce_2candles_rigid" you could just change the spawnarg "attach_pos_origin_1" to whatever new origin you would like which would change the position of the actual light entity on the object when it gets spawned in.


The Accountant
Part 1: Thieves and Heirs | Part 2: New In town

 

Shadows of Northdale Campaign

ACT I
 
Stand Alone Missions
Lord Edgar's Bathhouse | Spring Cleaning


#3 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 18 April 2018 - 03:58 PM

hmm, I've never created that type of entity before but this might fix another issue I have run into. The models has 12 'bulbs' where I want to attach func_emitters, I assume I could use the same trick for the light on the emitters..?



#4 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8866 posts

Posted 18 April 2018 - 04:52 PM

Yep, here's the reference.

http://wiki.thedarkm...itle=Def_attach

Similar topic:

http://forums.thedar...lapping-lights/
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

(Yeah, shameless promotion... but traffic is traffic folks...)

#5 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 18 April 2018 - 06:03 PM

Ok, so let me ask this, how many def/pos attach's can we have? as I need to do 12.



#6 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 19 April 2018 - 02:43 AM

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.


  • Bikerdude 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.

#7 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 19 April 2018 - 05:15 AM

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

What I have is

I need to offset the origin of the light so its below the model and the light center is in line with the bulbs. Then def attached all the emitters to the bulbs.


Edited by Bikerdude, 19 April 2018 - 05:15 AM.


#8 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 19 April 2018 - 08:38 AM

Well it looks like you cant def_attach particles, so am trying to create a custom entity with a single particle


  • Judith likes this

#9 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1323 posts

Posted 19 April 2018 - 08:46 AM

That might eat up performance pretty quick too, both because of number of emitters and particles generated, and/or because of transparency overdraw. A lot depends on how well the emiter is made. One or two static particles would probably be fine, but I imagine placing 2 or 3 such chandeliers in a scene might cause a slowdown.

 

Edit: too slow :) one particle would probably be a good solution.


Edited by Judith, 19 April 2018 - 09:02 AM.


#10 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 19 April 2018 - 09:17 AM

one particle would probably be a good solution.

I guess a single custom particle would cleaner in the def at-least.

 

Well rather annoyingly, the new "func_bulb" entity appears in game just fine when I place it in DR - but is not appearing, def_attaching on the model.


Edited by Bikerdude, 19 April 2018 - 09:19 AM.


#11 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 19 April 2018 - 10:26 AM

I created a single custom particle, as this cuts down the on the entity count and for now I am just gonna place the new "atdm:func_chandelier_emitter" entity in the map, I cant figure out why the bloody thing wont def_attach.

 

bhm_2018-04-19_16.20.13.jpg

 

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

 

Spoiler

Edited by Bikerdude, 19 April 2018 - 10:27 AM.


#12 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 19 April 2018 - 01:09 PM

  • Why don't you inherit the emitter from func_emitter then from func_static?
  • Is there any console output that might be of use to hunt down the error?
  • Is the chandelier moving?

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.

#13 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 19 April 2018 - 03:21 PM

  • Why don't you inherit the emitter from func_emitter then from func_static?
  • Is there any console output that might be of use to hunt down the error?
  • Is the chandelier moving
  • Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.
  • Didnt think to check, will a normal console output show anything though..?
  • nope, static.


#14 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 19 April 2018 - 04:26 PM


Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

No, I've meant the following.

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" // <<<<------------------------------
    "editor_color"                    "0.875 0.878 0.804"
    "editor_mins"                    "-12 -12 -12"
    "editor_maxs"                    "12 12 12"
    "editor_rotatable"                "1"
"cycleTrigger"          "0"
    
    "editor_displayFolder"                "Func"
    "editor_usage"                        "custom light bulb emitter for bhm chandelier"
    "editor_bool start_off"                "0" //if set to 1, particle system will not be visible on spawn."
    
    "editor_setKeyValue model"         "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created
    
    "solid"                        "0"
    "noclipmodel"                    "1"
    "spawnclass"                    "idFuncEmitter"
    "start_off"                    "0"
}

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.

#15 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 19 April 2018 - 04:39 PM

 

No, I've meant the following.

    "inherit"                    "func_emitter" // <<<<------------------------------

It doesn't apply because I am using the def of the func_emitter entity as a template, creating a new func_emitter with a predefined particle.



#16 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 20 April 2018 - 02:28 AM

Func_emitter is only a rough wrapper which starts working once additional spawnargs (like the prt to use) has been specified. When defining a new entity you do exactly the same. Inherit gets the entity you want to start off with (in your case func_emitter), and then you just add the spawnargs needed. That's the whole point of inheritance. Your definition should actually look like this

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.


  • 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.

#17 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1323 posts

Posted 20 April 2018 - 02:39 AM

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.



#18 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 20 April 2018 - 03:31 AM

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Fair enough, will give that a try.


Edited by Bikerdude, 20 April 2018 - 03:31 AM.


#19 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 20 April 2018 - 03:54 AM

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

That is basically how it works. The whole idea behind this concept is that you try to keep the amount of repetition as low as possible. This basically comes from programming, where several types of constructs (called structs or classes/objects in modern programming languages) may do similar things. In that case you would have to write the same piece of code over and over agian. Instead you define a basic class that implements all the features that are shared by all your constructs, and in the latter you only have to specify what is specific to them.

 

The inheritance in entity definitions work the same. For example you create a basic entity definition for ai, which specifies all the things that are common among all ai. This is not a working ai yet, as lots of imformation are missing (like the specific model to use, the vocal set or whatever), but you have a blueprint for all your ai now. When you then create a specific ai, like a builder guard, you let it inherit from your base class (it now has all the features and properties specified there), and only add what is needed and may change what differs from the default values set in the base class. This way you can save a lot of time. In addition, if you want to make a change to all ai, like changing the scriptobject to use, you only have to make that change in the base class, instead of doing so for all dozens of ai entities you may have defined. All ai will inherit the change from the base class (hence that naming).

 

https://en.wikipedia...ed_programming)


  • 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.

#20 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 20 April 2018 - 04:01 AM

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Obs your a little star, as soon as I changed to the above and def_attched it to the new light entity it worked in-game. I had just been overcomplicating things, nice one fella!


Edited by Bikerdude, 20 April 2018 - 04:13 AM.


#21 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 20 April 2018 - 04:05 AM

Thou art welcome, Sir Dude :)


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.

#22 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 20 April 2018 - 04:12 AM

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

@Obs, got any ideas or pointers on the the above..?


Edited by Bikerdude, 20 April 2018 - 04:13 AM.


#23 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 20 April 2018 - 05:28 PM

Use the skin spawnarg. (The one you've commented out ;) )


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.

#24 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19973 posts

Posted 21 April 2018 - 04:23 AM

That makes sense, I can use the lit skin as the normal skin. I was confused by the way its done on all other lights, so maybe in those instances the plain skin was just a lit skin?



#25 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5608 posts

Posted 21 April 2018 - 05:23 AM

skin is the spawnarg used by the engine to determine whether and what skin should be used. skin_lit and skin_unlit are used by the scriptobject (tdm_light_holder). The script changes the skin once the light status changes. IIRC it doesn't check for the initial state after spawn and choose the proper skin. Might be worth tweaking that in the future so that the skin spawnarg becomes unneccessary on entities using said scriptobject.


  • Bikerdude 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.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users