Open Development User Group/Archive/2023-12-13
Vir Linden: Hi folks!
dantia Gothly: Good morning Vir.
Vir Linden: Big turnout today
Yuzuru Jewell: :)
dantia Gothly: I'm trapped in here. inside secondlife. send help.
dantia Gothly: don't turn off the server.
Vir Linden: You're safe until the next restart :-)
Kasumi Ravenheart: Greetings!
Vir Linden: So, viewers. PBR is out!
dantia Gothly: Proud of you.
Erik Kundiman: congratulations!
Henri Beauchamp: Yes... a bit too soon, sadly, given all the issues... :-P
Vir Linden: Coming next is one of Maint V, GLTF Maint, or emojis. Don't know which yet
dantia Gothly: hay if you waited for everything to be fixed it would never be out.
Kasumi Ravenheart: omg emojis lol
dantia Gothly: nice.
dantia Gothly: what news on the scripting front?
dantia Gothly: I've seen a bunch of updates to the wiki.
Henri Beauchamp: /me prefers old-style smileys... :-P
Vir Linden: Don't think we'll have another promotion before end of year, though, break coming soon
Vir Linden: Which updates have you been seeing?
dantia Gothly: game control
Henri Beauchamp: Server side ones
Henri Beauchamp: Game control is not yet committed viewer-side.
Vir Linden: I don't have the latest on those, would probably find more at the server user group
Vir Linden: Also on the subject of scripting, though, we've been having some discussions on viewer-side scripting. Nothing definite yet, just exploring the possibilities.
Henri Beauchamp: @Vir: try this http://sldev.free.fr/CoolVLViewerLuaManual.pdf
Kasumi Ravenheart: I would love to know if there is improvements for texture creating for pbr, for example the hdri and setting different logiciels specially if OCIO can be used
dantia Gothly: Are we talking like, plugins?
dantia Gothly: Python or C#/C++?
Vir Linden: Potentially, yes
Kasumi Ravenheart: wow
Kasumi Ravenheart: nice
Vir Linden: Anyway, it's not at all definite, but I'm curious if you think it would be useful, and what you would use it for
dantia Gothly: That could be cool. I could make my sprite sheet creator an SL plugin.
dantia Gothly: I could see it being used to bridge gaps between blender and SL
dantia Gothly: for a lot of things
Vir Linden: Internally would be handy for things like test automation too
Henri Beauchamp: /me found viewer-side scripting useful enough to implement Lua scripting for the Cool VL Viewer: it allows to automate things, customize the features and UI, etc...
Vir Linden: Do you have a plugin system for it?
polysail: LUA ... in SL sounds like ~ the worst possible choice.
dantia Gothly: its not great.
Henri Beauchamp: No plugin, no, just script files, with pre-processing too (cpp-like), so you can #include modules, if you want. I also have D-Bus support, under Linux (meaning the veiwer can exchange data with other processes via D-Bus.
polysail: I get that "something is better than nothing" ~ but ~ in the case of LUA maybe not even that is true.
Henri Beauchamp: Lua is GREAT. Small, super fast, easy to learn and script.
polysail: Henri ~I do not share your enthusiasm for LUA.
Henri Beauchamp: /me shrugs, "Because you did not try it" :-P
dantia Gothly: Python would be better if given a choice.
Vir Linden: Lua is pretty widely used as a base for mods by other games and apps, fwiw
polysail: Python comes with it's own hoard of issues ~
Henri Beauchamp: EWWWWWW !... Do not BLOAT the viewer with Python, Javascript or what not, please !!!
dantia Gothly: C# then.
Vir Linden: What would you use, polysail?
Henri Beauchamp: Same: C# is Windoze only too...
dantia Gothly: back to python it is.
Henri Beauchamp: Lua is only a few dozen KB added (the Lua library is quite small), and statically linked to the viewer, without any external dependency.
polysail: Hmm ~ I forgot C# is windows only.
Vir Linden: Something that's lightweight and embeddable is a big plus.
dantia Gothly: python packages aren't that big of a deal with the amount of memory today's systems can store and pass around.
dantia Gothly: lua feels like another limited ball and chain for creators.
Henri Beauchamp: Python itself is HUGE. Packages are just like added libraries. And there are too, many dependencies.
Vir Linden: Trying to maintain a whole python ecosystem on every client machine worries me, tbh
polysail: I mean ~ Python WOULD be nice~ Considering it's just viewerside scripting support.
polysail: It's got a lot of issues
polysail: But ~
polysail: any techy-artist-type is going to know it
Henri Beauchamp: @Dantia:Lua is used in many, many, many AAA games.
dantia Gothly: I know. I can read and write it.
polysail: Just to be clear we're talking about viewerside script implementation for automated testing
polysail: as in
polysail: something the standard user would not need nor want ~ and has no impact on performance ~ other than the excessive number of requests it'll be able to generate correct?
Henri Beauchamp: Lua is not limited the least. Do have a look at what I did for my viewer, and you will see...
polysail: Like ~ something the QA team would *love* right Vir?
Vir Linden: Not necessarily just QA automation. Could support user-created scripts, could be used to provide plugins (as it does for many games)
polysail: Okay ~ Plugins but like
polysail: ...
polysail: I feel like plugins that could affect the SL world
Vir Linden: We already have some internal tools for QA automation using python, and even keeping them working for us is sort of a pain. But it is certainly possible to do
polysail: will very rapidly become a security vector.
Henri Beauchamp: I even implemented threaded Lua scripts support...
polysail: so I'm a little uncertain how to approach something like that ~
dantia Gothly: Vir, would these plugins have the ability to spawn floaters that have controls on them or would they also have to have a floater.xml file along with the plugin in order to do such a task. I think some of those things should be a consideration given that the existing UI isn't that flexible.
polysail: if you're trying to do UI stuff ~ LUA is .. ( I will begrudgingly admit ) superior to Python, but ONLY for UI stuff.
Henri Beauchamp: @Dantia: you can already have custom Lua floaters in the Cool VL Viewer. http://sldev.free.fr/CoolVLViewerLuaManual.pdf
dantia Gothly: In blender I can make a plugin that make a tab in the 3D view port with controls all within a single script I would expect to be able to create UI elements with plugins for SL.
Vir Linden: If we went down a plugins route, we would certainly need to create new UI elements and associate them with functions. It might be hard to get enough control without also allowing for xui files
polysail: Well
polysail: Here ~
polysail: before we start to boil the ocean of entirely rebuilding the whole SL UI
dantia Gothly: lol
dantia Gothly: Its a rabbit hole man.
polysail: are we primarily trying to add new functionality to the Viewer via plugins ? Or are we trying to give people the option to rearrange the UI and create new floaters for *already existing utlities* ~
Henri Beauchamp: @Dantia: there are already Lua side bar buttons, Lua status bar icon, Lua tool bar button, Lua pie menu, Lua copy/paste menu entries, simple Lua dialogs, custom (and as complex as you want) Lua floaters, etc, in the Cool VL Viewer
polysail: because the former is Pythons strength ~ the latter is LUA's
dantia Gothly: The interface is very messy and it makes me sad every time I edit a floater file.
polysail: XUI is a pain and I hate it
polysail: but I hate a lot of things
polysail: that require programming and boilerplate stuff
polysail: so yeah ~
Vir Linden: What we would not be doing is rewriting the entire viewer so there is a nice clean interface to build everything on top of. But we could look for opportunities to make the exposed API cleaner than the underlying code
polysail: This sentence scares me : "opportunities to make the exposed API cleaner than the underlying code"
Vir Linden: That's a pretty standard thing to do in the refactoring world as well
Vir Linden: If you can't fix everything at once, you start with the controls/API and work your way down the stack as time allows
polysail: Ehmmm yeah ~
polysail: I guess ~
polysail: I dunno ~I feel like putting a fancy interface on a pile of spaghetti is just going to be painful to everyone.
dantia Gothly: Has any progress been made on PBR Terrain?
dantia Gothly: or the mirrors Green was working on.
Vir Linden: PBR terrain is on hold for right now while the graphics folks are working on PBR bugs. Hoping to tackle it soon though
Henri Beauchamp: PBR terrain is muddy... :-D
Vir Linden: Same story for mirros
Henri Beauchamp: Mirrors will be super costly, fps-wise...
dantia Gothly: we will see
wildthang2: any plans to improve sim crossing? :D
Vir Linden: Mirrors certainly won't be free FPS-wise. That was always one reason we pushed back on the request... lots of popular demand though
dantia Gothly: I'm sure they will find a nice happy medium for us and give us some options we can play with in the graphics settings.
Vir Linden: That's usually the way it works out
Henri Beauchamp: Sim crossing is mainly a server side (and/or protocol) issue... Ask in the Server User Group.
wildthang2: ah my bad
Henri Beauchamp: @Vir: what VS2022 version you are using to build the official release (PBR) viewer now ? This question is because while former viewer builds (including PBR RC) were running Ok under Wine, the latest release PBR viewer is a total crash fest (it survives only a few seconds to a couple minutes after login before crashing, and only on the condition to not move the camera too much; likely a crash while rezzing some objects, or connecting to a neighbour region). Since I have seen this happening with my own viewer when built with MSVC1937 (VS2022 v17.7) and *not* with MSVC1936 neither with the newest MSVC1938 (VS2022 v17.8), I am wondering if you are using MSVC1937 right now... If yes, then I'd encourage you to update to MSVC1938. If not, then there is either a bug in the PBR viewer code that gets triggered by Wine, or a bug in Wine triggered by some new code in the release PBR viewer latest commits.
Vir Linden: Hmm, good question. Depends on how the GHA runners are set up, which I don't know off-hand. Will see if I can get an answer
dantia Gothly: Can you tell me if chat logging and the interface update with that is on the same thread as everything else or is and or can that be handled on another thread. I noticed that objects sending a lot of ownersay message cause the client FPS to tank very hard. https://cdn.discordapp.com/attachments/681996187162640406/1184010607347904542/image.png?ex=658a6ace&is=6577f5ce&hm=5c9066897f64324c387c999a9835f1ae75a28af478392014fd0c6e3509cd384d&
Henri Beauchamp: In any case, if it's MSVC1937, update it...
Henri Beauchamp: There is no chat threading: it's processed in the main (also rendering), thread.
Henri Beauchamp: Your issue could be related to the RLV(a) implementation: RLV is using llOwnerSay("@stuff") to receive commands...
Vir Linden: I think that's right. We are pulling things into separate threads based on where we find stalls - but of course that depends on the use cases too. We may not be hammering chat as hard in our tests
dantia Gothly: I'm using the LL viewer.
dantia Gothly: no RLV
Vir Linden: dantia could you file a bug report on this? Anything to help us repro (like sample objects) would be very helpful
dantia Gothly: yeah its an owner say in a while true loop lol
dantia Gothly: it crushes the fps.
dantia Gothly: I thought it was particles at first
Henri Beauchamp: Might need some throttling server side to avoid llOwnerSay() spamming....
Vir Linden: hmm, maybe add some sleeps or something
dantia Gothly: I mean yeah. but something to prevent the client from hanging while the chat window updates.
Henri Beauchamp: Could throttle viewer side too, for the chat printing, but would still receive lots of UDP messages to process nonetheless
Vir Linden: UI is pretty much all in main thread now. We will continue making threading changes based on where we see issues (or get bug reports about issues, hint, hint :-) )
dantia Gothly: llSay throttles after so may messages are printed but thats to prevent local chat spam. I don't mind if the ownersay chat spams me I just care that it tanks my FPS when updating the client.
dantia Gothly: yeah ok lol
dantia Gothly: I just wanted to ask because I needed more info before I spend the time making it.
Henri Beauchamp: What do you mean by "tanks my FPS when updating the client" ?...
dantia Gothly: when the interface updates with the chat message
Henri Beauchamp: Well, you can still mute/block the offending/spamming object...
dantia Gothly: but what if its my object and I want it to send messages. o.o
dantia Gothly: lol
Henri Beauchamp: Then you are a masochist ! :-D
dantia Gothly: yes
dantia Gothly: Hello, content creator on SL.
Vir Linden: LOL
Kasumi Ravenheart: accurate
Vir Linden: Anyway, we're open for new topics, or ideas about client-side scripting, etc
dantia Gothly: prim_surface_text
dantia Gothly: PRIM_TEXTURE_ANIM
dantia Gothly: >_>;
dantia Gothly: animated particles.
Henri Beauchamp: LSL requests go to the SUG too... :-P
dantia Gothly: Animated Projectors >_>;
polysail: Back to the scripting language debate ~ now that I've had some more time to sort of collect my thoughts into coherent words. I think what I was trying to say earlier is ~ if we're trying to provide UI enhancements without providing any additional utility that might be a security hazard IE a "Copybot plugin" then LUA is a relatively safe choice as it's so hobbled in it's capabilities that it is safe ~ however from a testing and automation / utliity standpoint ~ something like Python or C# would be immensely beneficial ~ but I don't see how you can bring that sort of utility to the viewer without someone inevitably trying to use it as a security leverage point.
Henri Beauchamp: Animated particles would be possible and much less taxing, with a Vulkan renderer...
Vir Linden: Vulkan is on the roadmap, but farther down the road...
Henri Beauchamp: /me very much hopes for Vulkan "soon enough"...
Yuzuru Jewell: Vir, can I download viewers built with actions on GitHub?
dantia Gothly: Zani and I were talking about flipbook like assets like in Unreal.
Henri Beauchamp: Good question Yuzuru: we need this to figure out if our PRs are valid/working...
Vir Linden: Yuzuru, all the recent viewer builds are made with github actions - you can grab the default viewer or most of the alternate viewers (we may still have one or two that haven't been brought over yet)
Vir Linden: Oh, you mean get them directly from github?
Henri Beauchamp: @Vir: the question is: would it be possible to have the viewer built when we create a PR and be able to get the corresponding built binary to test it ?
Yuzuru Jewell: yes. Do you have a plan about it?
Vir Linden: Henri: yes, we are planning to do that, don't have it set up yet
Yuzuru Jewell: OK. I see. I remember hearing such an idea here... Thank you, VIr.
Vir Linden: Yuzuru: I think so, asking in slack to see if I can get details on the sequence of steps
Henri Beauchamp: I could contribute a lot more, if we could do this.... My viewer code base is too far apart from LL's now, to create a PR from a diff with my code. So I need an easy way (and transparent for me, building-time and resource-wise) to be able to push code changes, and test them with the corresponding binary.
Yuzuru Jewell: My question was not appropriate. Excuse me..
Vir Linden: Henri, is your viewer set up to build inside GHA runners?
Vir Linden: Yuzuru, question is fine, I just don't have the answer yet :-)
Henri Beauchamp: @Vir: I do not have my viewer code on github or any such repository. I build it only locally, from sources, with a self-contained build system. It builds in 3 minutes with just a single script/batch file. :-P
Yuzuru Jewell: There is a saying in Japanese that goes, "No news is good news." :)
Vir Linden: Henri - so you are just wondering about getting builds for PRs based off of our viewer?
Vir Linden: Yuzuru - nat says "You start with the Actions link at the top middle of the page. There you can filter actions builds by branch."
Henri Beauchamp: @Vir: I create PRs by modifying LL's code, line by line, porting it from my own code in my own viewer... yes, it takes time, and no, I cannot afford building the resulting viewer myself after all that time spent already... Thus why, once I push the PR to LL's github, I just want to get a binary some time later to test big changes that might compile fine but not work as expected...
Yuzuru Jewell: Thank you, VIr. I can see them.
Vir Linden: I guess that's about all for today. Good to see and hear from so many folks