Wed, Feb 19, 2:06 AM CST

Renderosity Forums / Poser Python Scripting



Welcome to the Poser Python Scripting Forum

Forum Moderators: Staff

Poser Python Scripting F.A.Q (Last Updated: 2025 Feb 05 6:41 am)

We now have a ProPack Section in the Poser FreeStuff.
Check out the new Poser Python Wish List thread. If you have an idea for a script, jot it down and maybe someone can write it. If you're looking to write a script, check out this thread for useful suggestions.

Also, check out the official Python site for interpreters, sample code, applications, cool links and debuggers. This is THE central site for Python.

You can now attach text files to your posts to pass around scripts. Just attach the script as a txt file like you would a jpg or gif. Since the forum will use a random name for the file in the link, you should give instructions on what the file name should be and where to install it. Its a good idea to usually put that info right in the script file as well.

Checkout the Renderosity MarketPlace - Your source for digital art content!



Subject: ockham: Is there Gravity in them thar Jiggles?


  • 1
  • 2
Tguyus ( ) posted Thu, 10 February 2005 at 1:44 PM · edited Wed, 19 February 2025 at 2:05 AM

Hi! I've been doing major pythoning in recent days using Jiggles, Emphasizer, Copier, and Sparsifier, and I'm starting to amass several Wish List kinds of things. At the risk of becoming a pest, I hope it's okay if I add some threads along the Wish List lines. PLEASE feel free to tell me to stop or slow down or go away if I'm asking for too much help.

Unless you ask me to do otherwise, I'll figure it's okay for me to put these ideas / requests on the table as individual threads (the better to work through / ignore / delete each question or request or idea).

So.... here's the first...

On Jiggles (version 4 from --I think-- March 2004), I'm finding that the Gravity slider seems not to have it's intended effect of adding a downward bias in Up-Down MT changes. I even tried going into the script and hardwiring in zero then positive values for the Grav variable to no effect. Does the Gravity slider work for you?

Thanks! TG


ockham ( ) posted Thu, 10 February 2005 at 2:06 PM

See the "detecting actor rotation" thread down a few... I just found a fresh solution to the gravity problem, which also gives me a way to redo Jiggles so it's damn near automatic. No more need to determine beforehand which morphs are up-down and side-side.

My python page
My ShareCG freebies


Tguyus ( ) posted Thu, 10 February 2005 at 2:30 PM

oboyoboyoboyoboyoboy!! I would LOVE to have a near-automatic Jiggles!

Here's what I do now when pythoning a female model's breast movement:

  1. Select chest and run Jiggles for the breastnatural MT.

  2. My ultimate target is a magnet rather than a MT, so I then run Copier to do two things: (a) transfer the breastnatural MT animation to my magnet prop and (b) embed a 5 frame lag.

  3. Delete the keyframes for the breastnatural MT.

So it would be absolutely fantastic if any new Jiggles script could both (a) allow targeting of parameters in a prop (e.g., the ytran of a magnet) and (b) specify source and target keyframe ranges to allow lags.

(I sure have my Wishing Cap on today, eh?) TG


ockham ( ) posted Thu, 10 February 2005 at 2:36 PM

Try out the simple script pasted in that thread. It's already pretty good for applying gravity to a chest; you can adjust the Proportion number at the top if it's too strong or weak. I'll try to add in the magnet-parm choice, and the lag. Would a ramp-up be better than a lag? Simulating internal viscosity, I suppose....

My python page
My ShareCG freebies


Tguyus ( ) posted Thu, 10 February 2005 at 3:01 PM

"Holy Cow! Observe the magnitude of the internal viscosities on that distaff-variety homo sapiens!" hehe

... Seriously, a ramp-up would be an interesting approach to test.

Going to test the script fragment now...


Tguyus ( ) posted Thu, 10 February 2005 at 3:10 PM

hmmmm... selected the chest and ran the script on a 92 frame animation with the model taking two quick hops in the first 30 or so frames. The result was that virtually all the MTs for the chest were modified, and just in frame 1. Does the WorldVertex stuff only apply to P5? I have P4PP.


ockham ( ) posted Thu, 10 February 2005 at 4:14 PM

file_183611.jpg

Oh, that little script doesn't run frames. It was just a test rig.... Sorry about that. Here's an alternate that sets every 5 frames.

My python page
My ShareCG freebies


Tguyus ( ) posted Thu, 10 February 2005 at 4:40 PM

Heading for home and will check it out later this evening. Thanks! TG


ockham ( ) posted Thu, 10 February 2005 at 4:48 PM

Question about typical magnet usage... I think I can treat the X,Y,Z tran as 'morph target equivalents' for this purpose. Should I also check the movements of the mag zone, or would most folks only animate the mag itself?

My python page
My ShareCG freebies


Tguyus ( ) posted Thu, 10 February 2005 at 5:41 PM · edited Thu, 10 February 2005 at 5:41 PM

All of my animated magnet applications involve only the magnet itself, though I can imagine instances when animating the zone might be useful. But even for reactions like squashing (e.g., a rubber ball compressing when it hits the floor, or a water balloon flattening out when hurled), I would be inclined first to try changing the scale parameters of the magnet itself rather than animating any of the parameters for the zone.

Bottom line for me is that hitting just the tran parameters would do 99% of what I think I would use for gravity-related processes.

Message edited on: 02/10/2005 17:41


ockham ( ) posted Thu, 10 February 2005 at 5:47 PM

OK, I'll take it that way and see what happens.

My python page
My ShareCG freebies


Tguyus ( ) posted Thu, 10 February 2005 at 7:26 PM

Great! I'm really looking forward to seeing the new gravity solution in action!


ockham ( ) posted Fri, 11 February 2005 at 7:34 PM

Attached Link: http://ockhamsbungalow.com/SoundScape/Jiggles5.zip

Try this for a start. It'll certainly need some adjustment; may be too sparse in its handling of the morphs, and I don't have the magnet stuff in yet. Before I add more complexity, I'd like to know whether it seems to "drive" well, or does it understeer or skid..... Note that you don't need to separate the directions any more. Just hit Analyze, set the sliders, then hit Go.

My python page
My ShareCG freebies


Tguyus ( ) posted Fri, 11 February 2005 at 9:23 PM

Fantastic! Just got it and can't wait to try it! Will report back by tomorrow!


ockham ( ) posted Fri, 11 February 2005 at 9:26 PM

Okay. I think it may be backwards, which is why I used the word "skid"! Watch for further updates in the next hour or so, if I can figure out what's wrong.

My python page
My ShareCG freebies


ockham ( ) posted Fri, 11 February 2005 at 11:09 PM

Attached Link: http://ockhamsbungalow.com/SoundScape/Jiggles7.zip

file_183613.jpg

Since Python can't tell internally whether a magnet "affects" the given part, it has to check all mags on the figure, and lists those that appear to actually move the chosen part. Note that the X,Y,Z tran of each mag is treated just like one of the morphs on the chosen part.

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 10:41 AM

I've only been able to do a few tests so far, and in fact I'm now running through analysis again after having changed the sampling to every frame rather than every 10 frames. I did this in the hopes I could observe the effects of changes in CPS, Twang, and Lag more effectively (i.e., I think some of the effect of tweaking these settings was being obscured by the 1/10 sampling).

Other tweaks I made to the script for testing purposes include changing the sign of Grav in the equation where it is applied. I'm guessing this might mess things up on lateral movements, but I was finding that applying a positive setting to Grav was creating an upward rather than downward bias when applied to a Mag ytran for which negative values pull the parts down and positive push them up. My test figure is only moving up and down at the moment so I don't know the effect of changing the sign of Grav on side-side movements. Another workaround might be to rotate the base of the magnet 180 degrees. Will play with that more in a bit.

Before changing the sign in the Grav equation, I changed the min-max of the Gravity slider so it could go negative. Also, I changed the sensitivity since even a very small value of Grav (e.g., 0.2) was having a huge effect when being applied to the BrstNatural MT. I did this because the Multiplier seemed to have no effect so I couldn't otherwise dampen the Gravity effect to see how it was working.

I also reduced the sensitivity of the Lag slider since small values of lag (again, like 0.2) were imposing lags of something like 10-15 frames.

Ah... the Analyze just finished for the every frame test so I'll report back in a bit.

This is really great stuff!


ockham ( ) posted Sat, 12 February 2005 at 10:47 AM

Attached Link: http://ockhamsbungalow.com/SoundScape/Jiggles8.zip

Before you spend any more time, try this. I fixed several important errors....

My python page
My ShareCG freebies


ockham ( ) posted Sat, 12 February 2005 at 10:51 AM

Reading your msg now, I see that you caught the same errors I fixed. Gravity was indeed being used negatively, and the lag needed to have a smaller range. The multiplier wasn't being used at all. Does 0.2 seem to be a good max for gravity?

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 10:55 AM

More observations:

  1. The Gravity adjustment does indeed work. It seems to impose a constant adjustment; that is, the spline is shifted downward without being modified. That is a very helpful feature. A useful refinement might be to avoid applying the gravity adjustment in the early frames (like a ramp-up). In other words, at the start of a figure's sudden motion, the magnets / MTs would be in their normal initial position. Applying Gravity as it is applied in the current version of the script means the magnets / MTs are already pulled down before the motion starts.

  2. CPS seems to affect the amplitude of the spline but not its frequency (or, if you prefer, the periodicity of the "twanging"). But I may be missing the intent of the CPS factor. I noticed the effect of CPS was the same in Jiggles4.

More later! Back to testing!


ockham ( ) posted Sat, 12 February 2005 at 10:59 AM · edited Sat, 12 February 2005 at 11:01 AM

The CPS is only meant to apply to the twang.

Hmmm...
I think a single 'damping' adjustment would cover
these thoughts, along with (or really instead of)
the Lag.
But shouldn't gravity be present at all times?

Message edited on: 02/12/2005 11:01

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 11:29 AM

Just thought of something else re Gravity adjustment. I'm wondering if there's a way to make a positive value for Gravity influence the weights applied to upward versus downward motions. Currently, peaks and troughs of the affected spline are amplified equally. Perhaps the solution is to impose some type of nonlinear function to weight the adjustments (exponential? skewed normal to avoid extreme adjustments?) so higher Grav settings have a proportionally greater effect on downward adjustments.


ockham ( ) posted Sat, 12 February 2005 at 11:30 AM

Attached Link: http://ockhamsbungalow.com/SoundScape/Jiggles9.zip

file_183616.jpg

I replaced Lag with a first-derivative sort of damping, and the effect is pretty good, I think. It gives a startup lag and also slows things down in general. Upper trace is no damp; Lower is max damp.

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 11:33 AM

oops... cross post. Yes, thinking about it, you're right that Gravity should apply at all times. I guess it's tricky since gravity is already reflected in the shaping of the character at rest. So perhaps what I was looking for was gravity-based adjustment to the amplitude of the peaks and troughs of the ytran of the magnet / MT driven by motion of the parent body part. But my blood sugar is low so I may not be thinking clearly. More after lunch!


ockham ( ) posted Sat, 12 February 2005 at 12:27 PM

Thinking out loud..... I want to make this as automatic as possible. Instead of working each body part separately, it should be possible to choose at startup which set of parts you want to control. But because of ERC, any part can actually be controlled by any other part. So this could turn into a very long analysis... looking at [effects on 10 parts] * [control by 20 parts]! The basic question is: can I count on the controller always being upstream in terms of parenting? If so, the matrix becomes manageable. On Misaki, for example, the breasts actually reside on LCollar and RCollar, but their morphs are controlled by Chest. So if you select RCollar and LCollar as the parts you want to control, the script would look upstream to Chest, then to Abd, Hip, Body. It can save time by doing one check for each, and skipping the frame-analysis when a controller does nothing to the desired area.

My python page
My ShareCG freebies


underdog ( ) posted Sat, 12 February 2005 at 12:38 PM

I think you are making this too hard. What you want to do is let the user make these choices once per figure type and then save them to a configuration file. If you incorporate a file dialog box into this, I think you can make most of your analysis go away.

The analysis right now is killing the script. For example, I tried this on Voluptuous Vicky mags and ran into problems. First of all, I had to run the script three times, once for the left collar, once for the right collar and once for the chest. Each time I watched it analyze the effects the various "Shin" magnets were having on the motion (obviously none) and finally I decided to delete all of the non-essential magnets.

Another problem was that I would exit out of poser once in a while (or somehow get that Poser.ini file rewritten) and it would want to re-analyze a body part that I had already run the analysis on.

Of course, deleting those non-essential magnets isn't really a practical real-world solution, but might be cool if I could choose from a list of all morphs/magnets (yeah I know that's a huge list) and then SAVE that relationship to a configuration file that I can call back later. Then I might have half-a-dozen or more of these configuration files, but once they are out there (and folks could upload their own versions), they are DONE. They would only need to change if the figure or magnets acting on that figure changed.


ockham ( ) posted Sat, 12 February 2005 at 12:49 PM · edited Sat, 12 February 2005 at 12:52 PM

The analysis is already saved for one
body part in one animation. That can
easily be expanded to cover a set of
body parts.

You can't have a single default config for
each default model, because the analysis
includes the effect of morphs at each
position.

So the best situation would be one config
for one model in one animation. (Of course,
for 99.999999% of Poser users, "one animation"
means "one frame".)

As I mentioned in previous msg, doing
just one check for each controller will save
much of the analysis time, regardless
of what's written to a file.

Message edited on: 02/12/2005 12:52

My python page
My ShareCG freebies


ockham ( ) posted Sat, 12 February 2005 at 1:23 PM

Attached Link: http://ockhamsbungalow.com/SoundScape/Jiggles10.zip

Here's a version with file-open and file-save, and with the effect-filter on the analysis. Still using only one body part. The file-open pops up immediately at start; if you hit Cancel, you then have to Analyze. At the end of Analyze, file-save pops up.

My python page
My ShareCG freebies


underdog ( ) posted Sat, 12 February 2005 at 1:53 PM

A python script I worked on a long while ago did magnet moves based on sliders. I wonder if you might have any ideas on how I might analyze the motion of the character's chest using World.Matrix() and/or World.Quaternion() and then apply those motions to the various magnets attached to the chest and/or left-right collars, etc. Does that question even make sense? I am not sure how to articulate the thing that I am looking for. Essentially I am looking to transfer the inertia and subsequent oscillation from the total motion of a body part to certain other props (probably magnets, but could be other things too). If I understand what you are up to with the Jiggles script, you are looking at the effects of the morphs on how the geometries move around. But I want to move other objects in x-y-z, and probably rotate them as well, based on their motions.


ockham ( ) posted Sat, 12 February 2005 at 2:06 PM

In a sense, that's already what Jiggles is doing... analyzing the linear accelerations of the body part, and moving morphs and magnets accordingly. Jiggles doesn't include rotational acceleration, though it will account for some rotations indirectly if the body has bilateral parts. (As in breasts mounted on left collar and right collar; when the body Y-rotates, the separate linear acc of those two sides are seen by Jiggles.) Are you thinking mainly about angular acc?

My python page
My ShareCG freebies


underdog ( ) posted Sat, 12 February 2005 at 2:08 PM

I am trying the new Jiggles.V10 now. I was wondering why you need to analyze those pesky shin magnets. I don't think there is a way in poser python to tell that their magnets don't affect the chest body part, but I may be wrong. Is there some way to filter them by determining that the magnet base parent isn't this actor and the magnet hasn't been applied to this actor?


underdog ( ) posted Sat, 12 February 2005 at 2:15 PM

Are you saying you are adjusting the x-y-z for the magnet position? So you actually moving the magnet positions? I didn't realize that. I thought you were raising or lowering the values for each magnet, treating it like a morph target on the body part. I am afraid I don't understand angular momentum / accelleration, or the physics behind this, so I can't really answer your question.


ockham ( ) posted Sat, 12 February 2005 at 2:17 PM

Problem is that Python just can't spot the "affects" connection, and any magnet could actually be set up to affect any part. So the analysis has to check for effects. Maybe I should give a little dead-band on the check, to eliminate tiny effects. Since you have the magnets, could you test it? Change each of these lines: if Denom == 0.0: continue # just go on to next morph to something like if Denom < 0.0001: continue

My python page
My ShareCG freebies


ockham ( ) posted Sat, 12 February 2005 at 2:20 PM

Yes, I'm moving the xtran/ytran/ztran of the mags, which has the same kind of effect as adjusting a MT dial.

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 2:25 PM

It does seem like it makes sense to allow the user to limit both source and destimation parts / MTs / magnets. As I mentioned in earlier post, a comprehensive analysis examining all the hundred-plus magnets I have on my figures would take too long.

In terms of the scope of what I personally am looking/hoping for, it is analysis of the effect of the movement of a representative body part (say, the chest) on a small, selected set of magnets (or MTs). Sticking with the chest to breasts example, the chest is the next upstream part, and it's movement already captures by proxy all the motions of parts which are upstream of the chest (as long as we're assessing the chest part's motion through absolute space, which I take it we are). Once this motion is analyzed, I only need to apply it to magnets (or MTs... but I use magnets) which are attached to, or downstream of, the chest.

If I want to also analyze the same animation to get the swinging of a figure's earrings, I would just re-run the script targeting the head. This would actually allow the head and chest movements to differently affect their respective children parts / props.

Saving the analysis in a DAT file is a great idea and major potential time-saver. This would let me run the analysis just once for any given animation / body part combination. I have no problem with the idea of re-running the analysis for any new animation / body part combination. I would just create a library of DAT files.

Looking way ahead, my own personal ultimate Jiggles script would be a one-button operation which has fixed settings for Grav, Damp, Twang, target magnets, Sec, CPS, and Multiplier; all of which I would define once I had found the optimal settings for a given set of source and destination parts (i.e, one 1-button script for breast movement, one for earrings swinging, etc). So I would select head or chest and invoke the relevant one-button script and --Presto-- I come back a half hour later and the breast magnets or earring magnets are all animated. But even if that approach isn't feasible, the dialogue box approach is still fabulous!


underdog ( ) posted Sat, 12 February 2005 at 2:28 PM

I will try that. Right now I am wondering if it locks up when I alt-tab to another screen and then back. I definately lose the actual screen update. Just dragging the Tk box to somewhere else makes the text messages freeze. But it looks like it's still doing work so I will let it keep munching. As far as translating the magnet and adjusting the MT dial, moving a magnet around certainly changes the target's shape in different ways than tweaking that magnet dial. But I guess that's pretty obvious. I thought I had looked around for the "affects" list for magnets too. I guess it is yet another thing that poser-python doesn't have access to. Ah well..


Tguyus ( ) posted Sat, 12 February 2005 at 2:30 PM

oops... looks like I'm several posts behind... will try to catch up...


underdog ( ) posted Sat, 12 February 2005 at 2:33 PM

It looks like it might be locking up on me. I am still waiting for the analysis. But I don't know how long to wait and it's probably been about 10 or 15 minutes. I wish the poser/python interface was a bit better. There are many cases where these two don't play nicely and this is one of them. I am almost positive that it's still doing work, but without the feedback it becomes frustrating. If it hangs for more than half-an-hour, I am definately resetting it.


ockham ( ) posted Sat, 12 February 2005 at 2:36 PM

Yeah, Tkinter doesn't play well with Poser. Dragging the panel around can make it crash, and moving a scrollbar fast can crash. It's especially bad in P5, which has its own weirdness about window focus.

My python page
My ShareCG freebies


ockham ( ) posted Sat, 12 February 2005 at 2:48 PM

Earrings! Great idea. Definitely need to handle props attached to the body, and treat them the same as body parts. For that purpose, we'd need to control rotation parameters as well as morph targets. The one-button thing just requires adding a separate DAT file, containing the chosen MTs or parameters and the Grav/Damp stuff. I think it should stay separate from the Analysis file. Maybe when you hit Go, you get to pick the 'Moves' file, or cancel to make new settings?

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 3:13 PM

On scrollbar-crashing, I've found that Sparsifier, for example, would crash a lot if I tried to move the scrollbar too fast. But resizing the Sparsifier window to make it larger seems to have eliminated the crashing for me.


Tguyus ( ) posted Sat, 12 February 2005 at 3:15 PM

One-button approach -> yes! a quick-pick off a Moves file list should do the trick! Great idea!


ockham ( ) posted Sat, 12 February 2005 at 3:22 PM

" But resizing the Sparsifier window to make it larger seems to have eliminated the crashing for me." Interesting. Maybe TKinter gets especially tired when it has to truncate lines...?

My python page
My ShareCG freebies


Tguyus ( ) posted Sat, 12 February 2005 at 4:48 PM

That's my theory! It especially helped making the box taller so more of the potential target elements were already visible. On Jiggles10, I'm finding that when I choose chest, run analyze, modify a target mag, and then close script and then re-open it, it does ask for my DAT file on re-opening (with chest selected) but then it insists on analyzing again. I do save the DAT file when asked to do so, but I save it to a folder other than the default. Does it only allow loading of DAT files which are in the default folder (which I believe is the "Runtime" folder)?


ockham ( ) posted Sat, 12 February 2005 at 5:33 PM

Okay, I'll look at that problem. Would probably be easier if I hard-wire a specific folder for these DAT files. I think the problem has more to do with the Actor Name disagreeing with what's in the file. I'll be revising that part anyway, as I expand to handle all Actors, so whatever is wrong there will be fixed or gone by tomorrow.....

My python page
My ShareCG freebies


an0malaus ( ) posted Sun, 13 February 2005 at 4:46 AM

file_183621.jpg

Here's a modified version of ockham's morph analysis script posted in another thread which analyses all frames up to the currently selected one (should work on both Mac and PC P5 as no Tkinter use) for instantaneous gravity effects on selected collar morph targets controlled by the chest. This has no motion acceleration analysis other than gravity, so is useful for a series of non-animated still frames/poses in a scene. Care was taken to avoid the use of morphs which operate in opposite directions for the left and right collars, such as BrstLieDown or BrstCleavage, as gravity requires them to operate in the same direction regardless of the body's attitude (imagine lying on the side...) Script includes some tests to determine current morph dial values (rather than FBM or JCM influenced values returned by Parameter.Value() ) . File is FindAvDirs2.py



My ShareCG Stuff

Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.


ockham ( ) posted Mon, 14 February 2005 at 2:15 AM

Attached Link: http://ockhamsbungalow.com/SoundScape/Jiggles12.zip

file_183623.jpg

Not all the motions I want yet, but the basics are here. In this demo clip, I used a larger multiplier on the right earring. Usage is same as before. Select the earring itself, run Analyze, pick values. Also, I fixed the problem with magnets not being skipped to save time.

My python page
My ShareCG freebies


Tguyus ( ) posted Mon, 14 February 2005 at 7:55 AM

This is absolutely great! I can't wait to try out this new version. Will report back soon. Thanks ockham!


Tguyus ( ) posted Mon, 14 February 2005 at 8:19 AM

hmmm.... getting the following error trying to run Jiggles12:

Traceback (innermost last):
File "", line 594, in ?
File "", line 162, in init
File "RuntimePythonliblib-tktkFileDialog.py", line 74, in askopenfilename
return apply(Open, (), options).show()
File "RuntimePythonliblib-tktkCommonDialog.py", line 49, in show
w = Frame(self.master)
File "RuntimePythonliblib-tkTkinter.py", line 1406, in init
Widget.init(self, master, 'frame', cnf,, extra)
File "RuntimePythonliblib-tkTkinter.py", line 1084, in init
self.tk.call(
TclError: can't invoke "frame" command: application has been destroyed


ockham ( ) posted Mon, 14 February 2005 at 11:02 AM

Hmm. I don't get that error in either Poser. Tk's fileopen box sometimes "feeds through" a mouse-click to the underlying script, and the result looks like this error. Try sliding the file-open box up before clicking on anything????

My python page
My ShareCG freebies


Tguyus ( ) posted Mon, 14 February 2005 at 12:24 PM

Another Tk mystery which has gone away on its own after a reboot. Running Analyze now for Jiggles12! Then I'll affix some earrings to her head and see how that new subroutine works. I'm also wondering if I can use J12 to make her hair swing back and forth. Great fun!


  • 1
  • 2

Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.